From: Tomi Ollila <tomi.ollila@iki.fi>
To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org
Subject: Re: [PATCH 1/5] cli: Refactor option passing in the search command
In-Reply-To: <87k34rtoi2.fsf@steelpick.2x.cz>
References: <1411378679-7307-1-git-send-email-sojkam1@fel.cvut.cz>
	<1411378679-7307-2-git-send-email-sojkam1@fel.cvut.cz>
	<m27g0rpl6x.fsf@guru.guru-group.fi>
	<87k34rtoi2.fsf@steelpick.2x.cz>
User-Agent: Notmuch/0.18.1+119~g5d90feb (http://notmuchmail.org) Emacs/24.3.1
	(x86_64-unknown-linux-gnu)
Date: Mon, 29 Sep 2014 19:04:59 +0300
Message-ID: <m27g0m1kgk.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

On Thu, Sep 25 2014, Michal Sojka <sojkam1@fel.cvut.cz> wrote:

> On Thu, Sep 25 2014, Tomi Ollila wrote:
>> On Mon, Sep 22 2014, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
>>
>>> Many functions that implement the search command need to access command
>>> line options. Instead of passing each option in a separate variable, put
>>> them in a structure and pass only this structure.
>>
>> This patch looks good to me.
>
> Thanks for the review.
>
>> Although the test and the implementation in the next patches look OK, I'd
>> prefer the FLAG implementation Jani suggested earlier. IMO now that I
>> compare these two it looks cleaner and simpler...
>
> The question is which kind of simplicity you have in mind. I think that
> my version is simpler to type (less keystrokes). But if others have
> different opinion, I don't mind.

Less keystrokes for sure -- but these interfaces are usually accessed
programmatically... :D

>>
>> Tomi
>>
>> (*) IMO the default unique (when requested) would be exact case-sensitive
>> match of full name & address 
>
> Why do you think that case-sensitive address matching should be the
> default? In theory local-part can be case sensitive, but I've never seen
> that in reality. So this default would only be useful if you want to
> research how people type your email address :)

Well, in short, I think the lowest level of uniqueness should be simple
string match, and this should at least be available if not default --
to the extent gmime provides (maybe that is this way in your patch...),

...and therefore I'd like to have this address output solved first, then
we can experiment with the outputs provided and have better-educated
comments on this issue...

>> parts (phrase, address & comment); 
>
> What do you mean by phrase and comment? Address syntax is defined by
> http://tools.ietf.org/html/rfc5322#section-3.4.1.

in 

"Foo Bar" (company/city) foo.bar@example.org

and

"Foo Bar" foo.bar@example.org (company/city) 

Phrase would be "Foo Bar"
Address foo.bar@example.org
and comment (company/city)

As a side note, nottoomuch-addresses does some heuristics there, and think
the 2 options above are equal (as "Phrase" (comment) address) -- which
might the same InternetAddressMailbox provides :O

Also, it seems that nottoomuch-addresses lowercases 'address' for
comparison and storage ... I am not entirely sure whether I should provide
options to disable these heuristics -- if someone asks for the feature
then I probably will do :D

>> then (a subset of possible) options could be:
>>    +) case-insensitive (first match taken (or last match?) -- option?)
>>    +) unique email addresses (take phrase/comment from first/last?)
>>       --  or use first that has something additional to plain address
>>       --  or use last  that has something additional to plain address
>
> Yes, there is a lot of possible options. I don't think that notmuch has
> to support all of them. If people need something special like "use last
> that has something additional to plain address", they can always do
> --unique=none and do their own post-processing.

Ok, but something (we can further bikeshed with) needs to be selected :D

>
> -Michal

Tomi