From f5fa34e88deae8904515dfc9143bf9af5a46c8fb Mon Sep 17 00:00:00 2001 From: Michal Sojka Date: Sun, 14 Dec 2014 15:24:53 +0100 Subject: [PATCH] Re: New "notmuch address" command --- 46/98991dd9e89b3c9115ca7bf6231bb863857491 | 140 ++++++++++++++++++++++ 1 file changed, 140 insertions(+) create mode 100644 46/98991dd9e89b3c9115ca7bf6231bb863857491 diff --git a/46/98991dd9e89b3c9115ca7bf6231bb863857491 b/46/98991dd9e89b3c9115ca7bf6231bb863857491 new file mode 100644 index 000000000..24d02abc0 --- /dev/null +++ b/46/98991dd9e89b3c9115ca7bf6231bb863857491 @@ -0,0 +1,140 @@ +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 02E01431FC7 + for ; Sun, 14 Dec 2014 06:25:02 -0800 (PST) +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=[RCVD_IN_DNSWL_NONE=-0.0001] 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 rOqkO1S-asPJ for ; + Sun, 14 Dec 2014 06:24:58 -0800 (PST) +Received: from smtp.nextra.cz (smtp.nextra.cz [212.65.193.3]) + by olra.theworths.org (Postfix) with ESMTP id 83057431FB6 + for ; Sun, 14 Dec 2014 06:24:58 -0800 (PST) +Received: from resox (unknown [213.29.198.144]) + by smtp.nextra.cz (Postfix) with ESMTP id BA27A1903B; + Sun, 14 Dec 2014 15:24:53 +0100 (CET) +Received: from wsh by resox with local (Exim 4.84) + (envelope-from ) + id 1Y0A6P-0000ti-Fw; Sun, 14 Dec 2014 15:24:53 +0100 +From: Michal Sojka +To: Lele Gaifax , notmuch@notmuchmail.org +Subject: Re: New "notmuch address" command +In-Reply-To: <874mt19iho.fsf@nautilus.nautilus> +References: <878uid9qjl.fsf@nautilus.nautilus> + <87ppbpf8yy.fsf@steelpick.2x.cz> <874mt19iho.fsf@nautilus.nautilus> +User-Agent: Notmuch/0.19~rc1+7~gdb5e73a (http://notmuchmail.org) Emacs/24.4.1 + (x86_64-pc-linux-gnu) +Date: Sun, 14 Dec 2014 15:24:53 +0100 +Message-ID: <87388inway.fsf@resox.2x.cz> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +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: Sun, 14 Dec 2014 14:25:02 -0000 + +On P=C3=A1, pro 12 2014, Lele Gaifax wrote: +> Michal Sojka writes: +> +>>> An (almost) equivalent of "notmuch-addrlookup foo" could be "notmuch +>>> address to:foo* OR from:foo*", but it has at least one indesiderable +>>> difference: it seems considering the "CC" field, but always emits the +>>> "TO" content (i.e., assuming I have a message I sent to "john@doe.com" +>>> and CCed to "foo@bar.com", "notmuch address to:foo" emits +>>> "john@doe.com", not "foo@bar.com") so the candidates it generates are +>>> way too much. +>>> +>>> I don't know it that's done on purpose (I clearly miss the use case if +>>> so). +>> +>> Yes, this is expected behavior. Notmuch address is basically a wrapper +>> around search command. The command does not interpret the query at all, +>> because there might be no from:/to: term. The use case was to SIMPLIFY +>> address completers. +> +> Ok, even if I still miss the point of searching for an address and +> obtaining (only, see below) something (apparently) unrelated. +> +>>> I wonder if it would be reasonable adding a "--complete" flag to the +>>> "address" command that selects a more specific behaviour, so that +>>> "notmuch address --complete foo": +>> ... +>>> b) searches the given text only in the related headers (hiding the +>>> difference between "incoming" and "outgoing" messages,=20 +>> +>> This should be configurable, because --output=3Dsender is much faster th= +an +>> --output=3Drecipients. I think that ideal address completion should offer +>> you the addresses you have already written to, i.e. +>> +>> notmuch address --output=3Drecipient from:my@address to:"prefix*" +>> +>> But this may be too slow on non-SSD disks. Some users may therefore pref= +er +>> +>> notmuch address --output=3Dsender to:my@address from:"prefix*" +>> +>> which would be faster, but also includes every spammer/robot/... who +>> sends anything to you. +> +> Yes, seems reasonable! +> +>>> and not +>>> considering the body at all) +>> +>> What considers body now? +> +> Well, "notmuch address foo" currently does that, and that sounds useful, +> to obtain a list of recipients who talked about "foo". +> +>>> c) avoids the "bug"/"feature" explained above +>> +>> Yes, if you know the substring you are looking for, implementing a +>> filter would be trivial. +> +> It's not just a matter of filtering, but rather *which* address is +> emitted: trying it out, in the case above the "foo@bar.com" is not even +> mentioned in the output, because it appears only as a CCed recipient. + +Are you saying that Cc address is not printed or that you want it not to +be printed? If the former than it is a bug. The following test passes +for me, i.e. foo@bar.com is printed. + +diff --git a/test/T095-address.sh b/test/T095-address.sh +index ed0cac7..17a7b08 100755 +--- a/test/T095-address.sh ++++ b/test/T095-address.sh +@@ -145,4 +145,13 @@ cat <EXPECTED + EOF + test_expect_equal_file OUTPUT EXPECTED +=20 ++test_begin_subtest "Cc address is printed while searching for To address" ++add_message [to]=3Djohn@doe.com [cc]=3Dfoo@bar.com ++notmuch address --output=3Drecipients to:john@doe.com > OUTPUT ++cat <EXPECTED ++john@doe.com ++foo@bar.com ++EOF ++test_expect_equal_file OUTPUT EXPECTED ++ + test_done + +Cheers, +-Michal -- 2.26.2