On P?, pro 12 2014, Lele Gaifax wrote: > Michal Sojka <sojkam1 at 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 at doe.com" >>> and CCed to "foo at bar.com", "notmuch address to:foo" emits >>> "john at doe.com", not "foo at 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, >> >> This should be configurable, because --output=sender is much faster than >> --output=recipients. I think that ideal address completion should offer >> you the addresses you have already written to, i.e. >> >> notmuch address --output=recipient from:my at address to:"prefix*" >> >> But this may be too slow on non-SSD disks. Some users may therefore prefer >> >> notmuch address --output=sender to:my at 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 at 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 at 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 +test_begin_subtest "Cc address is printed while searching for To address" +add_message [to]=john at doe.com [cc]=foo at bar.com +notmuch address --output=recipients to:john at doe.com > OUTPUT +cat <<EOF >EXPECTED +john at doe.com +foo at bar.com +EOF +test_expect_equal_file OUTPUT EXPECTED + test_done Cheers, -Michal