From: Michal Sojka <sojkam1@fel.cvut.cz>
To: Lele Gaifax <lele@metapensiero.it>, 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
Precedence: list

On P=C3=A1, pro 12 2014, Lele Gaifax wrote:
> Michal Sojka <sojkam1@fel.cvut.cz> 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 <<EOF >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 <<EOF >EXPECTED
+john@doe.com
+foo@bar.com
+EOF
+test_expect_equal_file OUTPUT EXPECTED
+
 test_done

Cheers,
-Michal