--- /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 16C3F431FD5\r
+ for <notmuch@notmuchmail.org>; Fri, 12 Dec 2014 02:39:32 -0800 (PST)\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 M0j1sONixoH7 for <notmuch@notmuchmail.org>;\r
+ Fri, 12 Dec 2014 02:39:28 -0800 (PST)\r
+Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])\r
+ by olra.theworths.org (Postfix) with ESMTP id D3511431FBF\r
+ for <notmuch@notmuchmail.org>; Fri, 12 Dec 2014 02:39:27 -0800 (PST)\r
+Received: from localhost (unknown [192.168.200.7])\r
+ by max.feld.cvut.cz (Postfix) with ESMTP id 0A50D5CCE6A;\r
+ Fri, 12 Dec 2014 11:39:22 +0100 (CET)\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 kP_XeF-R0uVp; Fri, 12 Dec 2014 11:39:17 +0100 (CET)\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 5C3533CFEF4;\r
+ Fri, 12 Dec 2014 11:39:17 +0100 (CET)\r
+Received: from wsh by steelpick.2x.cz with local (Exim 4.84)\r
+ (envelope-from <sojkam1@fel.cvut.cz>)\r
+ id 1XzNcz-0005MV-1x; Fri, 12 Dec 2014 11:39:17 +0100\r
+From: Michal Sojka <sojkam1@fel.cvut.cz>\r
+To: Lele Gaifax <lele@metapensiero.it>, notmuch@notmuchmail.org\r
+Subject: Re: New "notmuch address" command\r
+In-Reply-To: <878uid9qjl.fsf@nautilus.nautilus>\r
+References: <878uid9qjl.fsf@nautilus.nautilus>\r
+User-Agent: Notmuch/0.18.2+178~g6e9e8bb (http://notmuchmail.org) Emacs/24.4.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Fri, 12 Dec 2014 11:39:17 +0100\r
+Message-ID: <87ppbpf8yy.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: Fri, 12 Dec 2014 10:39:32 -0000\r
+\r
+Hi Lele,\r
+\r
+On Fri, Dec 12 2014, Lele Gaifax wrote:\r
+> Hi all again,\r
+>\r
+> I'm happily using "notmuch-addrlookup"[1] as "notmuch-address-command", in\r
+> my Emacs configuration.\r
+>\r
+> As explained in my other message, yesterday I spent some time tweaking\r
+> that configuration and tried to replace it with the new "notmuch\r
+> address" introduced in version 0.19.\r
+>\r
+> An (almost) equivalent of "notmuch-addrlookup foo" could be "notmuch\r
+> address to:foo* OR from:foo*", but it has at least one indesiderable\r
+> difference: it seems considering the "CC" field, but always emits the\r
+> "TO" content (i.e., assuming I have a message I sent to "john@doe.com"\r
+> and CCed to "foo@bar.com", "notmuch address to:foo" emits\r
+> "john@doe.com", not "foo@bar.com") so the candidates it generates are\r
+> way too much.\r
+>\r
+> I don't know it that's done on purpose (I clearly miss the use case if\r
+> so).\r
+\r
+Yes, this is expected behavior. Notmuch address is basically a wrapper\r
+around search command. The command does not interpret the query at all,\r
+because there might be no from:/to: term. The use case was to SIMPLIFY\r
+address completers. \r
+\r
+> I wonder if it would be reasonable adding a "--complete" flag to the\r
+> "address" command that selects a more specific behaviour, so that\r
+> "notmuch address --complete foo":\r
+\r
+This would definitely be useful.\r
+\r
+> a) automatically performs a partial match (i.e. it adds the '*' suffix\r
+> on its own)\r
+\r
+OK\r
+\r
+> b) searches the given text only in the related headers (hiding the\r
+> difference between "incoming" and "outgoing" messages, \r
+\r
+This should be configurable, because --output=sender is much faster than\r
+--output=recipients. I think that ideal address completion should offer\r
+you the addresses you have already written to, i.e.\r
+\r
+ notmuch address --output=recipient from:my@address to:"prefix*"\r
+\r
+But this may be too slow on non-SSD disks. Some users may therefore prefer\r
+\r
+ notmuch address --output=sender to:my@address from:"prefix*"\r
+\r
+which would be faster, but also includes every spammer/robot/... who\r
+sends anything to you.\r
+\r
+> and not\r
+> considering the body at all)\r
+\r
+What considers body now?\r
+\r
+>\r
+> c) avoids the "bug"/"feature" explained above\r
+\r
+Yes, if you know the substring you are looking for, implementing a\r
+filter would be trivial.\r
+\r
+> What do you think?\r
+\r
+Another question is that uses may want to select which my@address to\r
+use. So maybe you can add --my-address option that allow specifying one\r
+or more addresses. If this option would not be given, all configured\r
+addresses in .notmuch-config would be used.\r
+\r
+So I think that --complete should just construct the query containing\r
+from:/to: terms and this should be concatenated with what user specified\r
+as a query. For example:\r
+\r
+ notmuch address --complete prefix tag:attachment\r
+\r
+-Michal\r