Re: [PATCH v3 10/10] cli: address: Add --filter-by option to configure address filtering

Subject: Re: [PATCH v3 10/10] cli: address: Add --filter-by option to configure address filtering

Date: Fri, 09 Jan 2015 16:29:17 +0100

To: Tomi Ollila, David Bremner, notmuch@notmuchmail.org

Cc:

From: Michal Sojka


On Fri, Jan 09 2015, Tomi Ollila wrote:
> On Fri, Jan 09 2015, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
>
>> Hi,
>>
>> sorry for longer response time :)
>>
>> On Thu, Jan 01 2015, Tomi Ollila wrote:
>>> On Wed, Dec 31 2014, David Bremner <david@tethera.net> wrote:
>>>
>>>> Michal Sojka <sojkam1@fel.cvut.cz> writes:
>>>>
>>>>> This option allows to configure the criterion for duplicate address
>>>>> filtering. Without this option, all unique combinations of name and
>>>>> address parts are printed. This option allows to filter the output
>>>>> more, for example to only contain unique address parts.
>>>>
>>>> I had the feeling there was some "controversy" about the UI here, but
>>>> following back the 3 versions of the series I didn't see it. Does that
>>>> mean we just need to sanity check the code, or are there outstanding
>>>> bikes to shed?
>>
>> I'd tend to rename this option to --unique as it was in some previous
>> version of the patch. Another thing in my mind is the implementation of
>> the --complete option mentioned in id:878uid9qjl.fsf@nautilus.nautilus.
>> This would also involve some kind of address filtering. I'll look into
>> this and send patches later.
>>
>>> I have intentionally been guiet on this during the review process of the
>>> other patches to not slow down the acceptance of the others. I have not
>>> got enough time to look the implemenentation or think this last patch
>>> further -- from the user interface point of view I recall seeing there
>>> both useless features (but which might be warranted by implementation
>>> simplicity) and missing features (but which might not be there due to 
>>> difficulty in implementation). Also, I am not sure whether the --filter-by
>>> is good option (and options descriptive...)...
>>
>> I'd be interested in what are these "missing features".
>
> Last night when I tried to catch sleep I was also thinking of this...
> ... let's see what I remember...
>
> First, Currently if we have addresses:
>
>  "Uni Que" <unique@example.org>
>  "Uni Que" <Unique@Example.Org>
>
> I presume these are thought as a separate addresses -- and an option to
> thought these as the same would be useful.

Yes, this would correspond to --unique=addrfold or --unique=nameaddrfold
from my patch.

> but let's consider second set of addresses:
>
>  "Uni Que" <unique@example.org>
>  "Uni Keko" <unique@example.org>
>
> Now, if there were an option to consider these 2 as the same, that would
> hide user from one of the names -- It is clear that "Uni Que" is the right
> one but if only "Uni Keko" (sleepyhead, that is) is shown user don't have
> a choice to select the right one. I am not sure what the use case for
> "uniquing" these 2 were.

For example, when you are interested in the number of people involved in
a discussion. You care only about the address and not about the names.
Perhaps you'd like to see only the addresses in the output and not the
names in this case, wouldn't you?

> Finally (for now), 3rd set of addresses
>
>  "Uni Que" <unique@example.org>
>  "Uni Que" <unique@foobar.invalid>
>
> Now, if there were an option to consider these 2 as same, and
> user is then given "Uni Que" <unique@foobar.invalid> (which clearly is
> the wrong one) I don't see the usefullness of this option...

I agree. This would correspond to --unique=name. So I'll drop this
option.

-Michal

Thread: