From: Tomi Ollila <tomi.ollila@iki.fi>
To: Michal Sojka <sojkam1@fel.cvut.cz>, David Bremner <david@tethera.net>,
	notmuch@notmuchmail.org
Subject: Re: [PATCH v3 10/10] cli: address: Add --filter-by
	option	to	configure	address filtering
In-Reply-To: <87egr46qcs.fsf@steelpick.2x.cz>
References: <1415147159-19946-1-git-send-email-sojkam1@fel.cvut.cz>
	<1415147159-19946-11-git-send-email-sojkam1@fel.cvut.cz>
	<87vbkrfs66.fsf@maritornes.cs.unb.ca>
	<m2d26yhfmk.fsf@guru.guru-group.fi>
	<87egr46qcs.fsf@steelpick.2x.cz>
User-Agent: Notmuch/0.19+14~ge04617b (http://notmuchmail.org) Emacs/24.3.1
	(x86_64-unknown-linux-gnu)
Date: Fri, 09 Jan 2015 16:13:00 +0200
Message-ID: <m2h9w0ujo3.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

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.

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.

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...

IMO I don't see a case having such an options there, but these are my 
opinions, feel free to bikes^H^H^H^H^H discuss further :D

Tomi

PS: The "missing features" not thought now -- the only one I can quickly
remember is uniq(1) style option -- uniq consecutive addresses to one --
to do this we'd first need the no-unique-at-all option... and of course
I have a use case for this :D

















>
> Cheers,
> -Michal
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch