[PATCH 1/5] cli: Refactor option passing in the search command

Michal Sojka sojkam1 at fel.cvut.cz
Thu Sep 25 13:48:53 PDT 2014


On Thu, Sep 25 2014, Tomi Ollila wrote:
> On Mon, Sep 22 2014, Michal Sojka <sojkam1 at 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.

> I.e. I'd prefer notmuch search --output=sender --output=recipients ...
> (same output regardless the order these options given).

This should be the case with both implementations.

> I'd postpone the unique handling to a bit later phase; there are quite a
> few options how to do that (*)
>
>
> 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 :)

> 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.

> 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.

-Michal


More information about the notmuch mailing list