From 9393126f87eed205e4792a2951d13271991e77ed Mon Sep 17 00:00:00 2001 From: Tomi Ollila Date: Mon, 29 Sep 2014 19:04:59 +0300 Subject: [PATCH] Re: [PATCH 1/5] cli: Refactor option passing in the search command --- f6/4975c26352d0005adf96120ad76e4ccf7f0d36 | 139 ++++++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 f6/4975c26352d0005adf96120ad76e4ccf7f0d36 diff --git a/f6/4975c26352d0005adf96120ad76e4ccf7f0d36 b/f6/4975c26352d0005adf96120ad76e4ccf7f0d36 new file mode 100644 index 000000000..6718391a4 --- /dev/null +++ b/f6/4975c26352d0005adf96120ad76e4ccf7f0d36 @@ -0,0 +1,139 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 65A0E431FC7 + for ; Mon, 29 Sep 2014 09:05:27 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id PCmNDRzGIVxx for ; + Mon, 29 Sep 2014 09:05:19 -0700 (PDT) +Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) + by olra.theworths.org (Postfix) with ESMTP id A0ABD431FCF + for ; Mon, 29 Sep 2014 09:05:18 -0700 (PDT) +Received: from guru.guru-group.fi (localhost [IPv6:::1]) + by guru.guru-group.fi (Postfix) with ESMTP id E39F5100063; + Mon, 29 Sep 2014 19:04:59 +0300 (EEST) +From: Tomi Ollila +To: Michal Sojka , 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> + + <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) +X-Face: HhBM'cA~ +MIME-Version: 1.0 +Content-Type: text/plain +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Mon, 29 Sep 2014 16:05:27 -0000 + +On Thu, Sep 25 2014, Michal Sojka wrote: + +> On Thu, Sep 25 2014, Tomi Ollila wrote: +>> On Mon, Sep 22 2014, Michal Sojka 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 -- 2.26.2