--- /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 02E01431FC7\r
+ for <notmuch@notmuchmail.org>; Sun, 14 Dec 2014 06:25:02 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_NONE=-0.0001] 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 rOqkO1S-asPJ for <notmuch@notmuchmail.org>;\r
+ Sun, 14 Dec 2014 06:24:58 -0800 (PST)\r
+Received: from smtp.nextra.cz (smtp.nextra.cz [212.65.193.3])\r
+ by olra.theworths.org (Postfix) with ESMTP id 83057431FB6\r
+ for <notmuch@notmuchmail.org>; Sun, 14 Dec 2014 06:24:58 -0800 (PST)\r
+Received: from resox (unknown [213.29.198.144])\r
+ by smtp.nextra.cz (Postfix) with ESMTP id BA27A1903B;\r
+ Sun, 14 Dec 2014 15:24:53 +0100 (CET)\r
+Received: from wsh by resox with local (Exim 4.84)\r
+ (envelope-from <sojkam1@fel.cvut.cz>)\r
+ id 1Y0A6P-0000ti-Fw; Sun, 14 Dec 2014 15:24:53 +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: <874mt19iho.fsf@nautilus.nautilus>\r
+References: <878uid9qjl.fsf@nautilus.nautilus>\r
+ <87ppbpf8yy.fsf@steelpick.2x.cz> <874mt19iho.fsf@nautilus.nautilus>\r
+User-Agent: Notmuch/0.19~rc1+7~gdb5e73a (http://notmuchmail.org) Emacs/24.4.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Sun, 14 Dec 2014 15:24:53 +0100\r
+Message-ID: <87388inway.fsf@resox.2x.cz>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Transfer-Encoding: quoted-printable\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: Sun, 14 Dec 2014 14:25:02 -0000\r
+\r
+On P=C3=A1, pro 12 2014, Lele Gaifax wrote:\r
+> Michal Sojka <sojkam1@fel.cvut.cz> writes:\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
+> Ok, even if I still miss the point of searching for an address and\r
+> obtaining (only, see below) something (apparently) unrelated.\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
+>>> b) searches the given text only in the related headers (hiding the\r
+>>> difference between "incoming" and "outgoing" messages,=20\r
+>>\r
+>> This should be configurable, because --output=3Dsender is much faster th=\r
+an\r
+>> --output=3Drecipients. I think that ideal address completion should offer\r
+>> you the addresses you have already written to, i.e.\r
+>>\r
+>> notmuch address --output=3Drecipient from:my@address to:"prefix*"\r
+>>\r
+>> But this may be too slow on non-SSD disks. Some users may therefore pref=\r
+er\r
+>>\r
+>> notmuch address --output=3Dsender 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
+> Yes, seems reasonable!\r
+>\r
+>>> and not\r
+>>> considering the body at all)\r
+>>\r
+>> What considers body now?\r
+>\r
+> Well, "notmuch address foo" currently does that, and that sounds useful,\r
+> to obtain a list of recipients who talked about "foo".\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
+> It's not just a matter of filtering, but rather *which* address is\r
+> emitted: trying it out, in the case above the "foo@bar.com" is not even\r
+> mentioned in the output, because it appears only as a CCed recipient.\r
+\r
+Are you saying that Cc address is not printed or that you want it not to\r
+be printed? If the former than it is a bug. The following test passes\r
+for me, i.e. foo@bar.com is printed.\r
+\r
+diff --git a/test/T095-address.sh b/test/T095-address.sh\r
+index ed0cac7..17a7b08 100755\r
+--- a/test/T095-address.sh\r
++++ b/test/T095-address.sh\r
+@@ -145,4 +145,13 @@ cat <<EOF >EXPECTED\r
+ EOF\r
+ test_expect_equal_file OUTPUT EXPECTED\r
+=20\r
++test_begin_subtest "Cc address is printed while searching for To address"\r
++add_message [to]=3Djohn@doe.com [cc]=3Dfoo@bar.com\r
++notmuch address --output=3Drecipients to:john@doe.com > OUTPUT\r
++cat <<EOF >EXPECTED\r
++john@doe.com\r
++foo@bar.com\r
++EOF\r
++test_expect_equal_file OUTPUT EXPECTED\r
++\r
+ test_done\r
+\r
+Cheers,\r
+-Michal\r
projects / notmuch-archives.git / commitdiff