--- /dev/null
+Return-Path: <sojkam1@fel.cvut.cz>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id EF6A1431FB6\r
+ for <notmuch@notmuchmail.org>; Thu, 25 Sep 2014 13:49:15 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.3\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id DAfOQHHqJzX9 for <notmuch@notmuchmail.org>;\r
+ Thu, 25 Sep 2014 13:49:10 -0700 (PDT)\r
+Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])\r
+ by olra.theworths.org (Postfix) with ESMTP id C1785431FAF\r
+ for <notmuch@notmuchmail.org>; Thu, 25 Sep 2014 13:49:09 -0700 (PDT)\r
+Received: from localhost (unknown [192.168.200.7])\r
+ by max.feld.cvut.cz (Postfix) with ESMTP id 742863CFEB1;\r
+ Thu, 25 Sep 2014 22:49:02 +0200 (CEST)\r
+X-Virus-Scanned: IMAP STYX AMAVIS\r
+Received: from max.feld.cvut.cz ([192.168.200.1])\r
+ by localhost (styx.feld.cvut.cz [192.168.200.7]) (amavisd-new,\r
+ port 10044)\r
+ with ESMTP id cu5E41uJeuaM; Thu, 25 Sep 2014 22:48:58 +0200 (CEST)\r
+Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])\r
+ by max.feld.cvut.cz (Postfix) with ESMTP id 96C533CFEA8;\r
+ Thu, 25 Sep 2014 22:48:58 +0200 (CEST)\r
+Received: from wsh by steelpick.2x.cz with local (Exim 4.84)\r
+ (envelope-from <sojkam1@fel.cvut.cz>)\r
+ id 1XXFy9-0002Z6-2R; Thu, 25 Sep 2014 22:48:53 +0200\r
+From: Michal Sojka <sojkam1@fel.cvut.cz>\r
+To: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH 1/5] cli: Refactor option passing in the search command\r
+In-Reply-To: <m27g0rpl6x.fsf@guru.guru-group.fi>\r
+References: <1411378679-7307-1-git-send-email-sojkam1@fel.cvut.cz>\r
+ <1411378679-7307-2-git-send-email-sojkam1@fel.cvut.cz>\r
+ <m27g0rpl6x.fsf@guru.guru-group.fi>\r
+User-Agent: Notmuch/0.18.1+101~g56b0ff0 (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Thu, 25 Sep 2014 22:48:53 +0200\r
+Message-ID: <87k34rtoi2.fsf@steelpick.2x.cz>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 25 Sep 2014 20:49:16 -0000\r
+\r
+On Thu, Sep 25 2014, Tomi Ollila wrote:\r
+> On Mon, Sep 22 2014, Michal Sojka <sojkam1@fel.cvut.cz> wrote:\r
+>\r
+>> Many functions that implement the search command need to access command\r
+>> line options. Instead of passing each option in a separate variable, put\r
+>> them in a structure and pass only this structure.\r
+>\r
+> This patch looks good to me.\r
+\r
+Thanks for the review.\r
+\r
+> Although the test and the implementation in the next patches look OK, I'd\r
+> prefer the FLAG implementation Jani suggested earlier. IMO now that I\r
+> compare these two it looks cleaner and simpler...\r
+\r
+The question is which kind of simplicity you have in mind. I think that\r
+my version is simpler to type (less keystrokes). But if others have\r
+different opinion, I don't mind.\r
+\r
+> I.e. I'd prefer notmuch search --output=sender --output=recipients ...\r
+> (same output regardless the order these options given).\r
+\r
+This should be the case with both implementations.\r
+\r
+> I'd postpone the unique handling to a bit later phase; there are quite a\r
+> few options how to do that (*)\r
+>\r
+>\r
+> Tomi\r
+>\r
+> (*) IMO the default unique (when requested) would be exact case-sensitive\r
+> match of full name & address \r
+\r
+Why do you think that case-sensitive address matching should be the\r
+default? In theory local-part can be case sensitive, but I've never seen\r
+that in reality. So this default would only be useful if you want to\r
+research how people type your email address :)\r
+\r
+> parts (phrase, address & comment); \r
+\r
+What do you mean by phrase and comment? Address syntax is defined by\r
+http://tools.ietf.org/html/rfc5322#section-3.4.1.\r
+\r
+> then (a subset of possible) options could be:\r
+> +) case-insensitive (first match taken (or last match?) -- option?)\r
+> +) unique email addresses (take phrase/comment from first/last?)\r
+> -- or use first that has something additional to plain address\r
+> -- or use last that has something additional to plain address\r
+\r
+Yes, there is a lot of possible options. I don't think that notmuch has\r
+to support all of them. If people need something special like "use last\r
+that has something additional to plain address", they can always do\r
+--unique=none and do their own post-processing.\r
+\r
+-Michal\r