1 Return-Path: <sojkam1@fel.cvut.cz>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by olra.theworths.org (Postfix) with ESMTP id 16C3F431FD5
\r
6 for <notmuch@notmuchmail.org>; Fri, 12 Dec 2014 02:39:32 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5
\r
12 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled
\r
13 Received: from olra.theworths.org ([127.0.0.1])
\r
14 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
15 with ESMTP id M0j1sONixoH7 for <notmuch@notmuchmail.org>;
\r
16 Fri, 12 Dec 2014 02:39:28 -0800 (PST)
\r
17 Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])
\r
18 by olra.theworths.org (Postfix) with ESMTP id D3511431FBF
\r
19 for <notmuch@notmuchmail.org>; Fri, 12 Dec 2014 02:39:27 -0800 (PST)
\r
20 Received: from localhost (unknown [192.168.200.7])
\r
21 by max.feld.cvut.cz (Postfix) with ESMTP id 0A50D5CCE6A;
\r
22 Fri, 12 Dec 2014 11:39:22 +0100 (CET)
\r
23 X-Virus-Scanned: IMAP STYX AMAVIS
\r
24 Received: from max.feld.cvut.cz ([192.168.200.1])
\r
25 by localhost (styx.feld.cvut.cz [192.168.200.7]) (amavisd-new,
\r
27 with ESMTP id kP_XeF-R0uVp; Fri, 12 Dec 2014 11:39:17 +0100 (CET)
\r
28 Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])
\r
29 by max.feld.cvut.cz (Postfix) with ESMTP id 5C3533CFEF4;
\r
30 Fri, 12 Dec 2014 11:39:17 +0100 (CET)
\r
31 Received: from wsh by steelpick.2x.cz with local (Exim 4.84)
\r
32 (envelope-from <sojkam1@fel.cvut.cz>)
\r
33 id 1XzNcz-0005MV-1x; Fri, 12 Dec 2014 11:39:17 +0100
\r
34 From: Michal Sojka <sojkam1@fel.cvut.cz>
\r
35 To: Lele Gaifax <lele@metapensiero.it>, notmuch@notmuchmail.org
\r
36 Subject: Re: New "notmuch address" command
\r
37 In-Reply-To: <878uid9qjl.fsf@nautilus.nautilus>
\r
38 References: <878uid9qjl.fsf@nautilus.nautilus>
\r
39 User-Agent: Notmuch/0.18.2+178~g6e9e8bb (http://notmuchmail.org) Emacs/24.4.1
\r
40 (x86_64-pc-linux-gnu)
\r
41 Date: Fri, 12 Dec 2014 11:39:17 +0100
\r
42 Message-ID: <87ppbpf8yy.fsf@steelpick.2x.cz>
\r
44 Content-Type: text/plain
\r
45 X-BeenThere: notmuch@notmuchmail.org
\r
46 X-Mailman-Version: 2.1.13
\r
48 List-Id: "Use and development of the notmuch mail system."
\r
49 <notmuch.notmuchmail.org>
\r
50 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
51 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
52 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
53 List-Post: <mailto:notmuch@notmuchmail.org>
\r
54 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
55 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
56 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
57 X-List-Received-Date: Fri, 12 Dec 2014 10:39:32 -0000
\r
61 On Fri, Dec 12 2014, Lele Gaifax wrote:
\r
64 > I'm happily using "notmuch-addrlookup"[1] as "notmuch-address-command", in
\r
65 > my Emacs configuration.
\r
67 > As explained in my other message, yesterday I spent some time tweaking
\r
68 > that configuration and tried to replace it with the new "notmuch
\r
69 > address" introduced in version 0.19.
\r
71 > An (almost) equivalent of "notmuch-addrlookup foo" could be "notmuch
\r
72 > address to:foo* OR from:foo*", but it has at least one indesiderable
\r
73 > difference: it seems considering the "CC" field, but always emits the
\r
74 > "TO" content (i.e., assuming I have a message I sent to "john@doe.com"
\r
75 > and CCed to "foo@bar.com", "notmuch address to:foo" emits
\r
76 > "john@doe.com", not "foo@bar.com") so the candidates it generates are
\r
79 > I don't know it that's done on purpose (I clearly miss the use case if
\r
82 Yes, this is expected behavior. Notmuch address is basically a wrapper
\r
83 around search command. The command does not interpret the query at all,
\r
84 because there might be no from:/to: term. The use case was to SIMPLIFY
\r
85 address completers.
\r
87 > I wonder if it would be reasonable adding a "--complete" flag to the
\r
88 > "address" command that selects a more specific behaviour, so that
\r
89 > "notmuch address --complete foo":
\r
91 This would definitely be useful.
\r
93 > a) automatically performs a partial match (i.e. it adds the '*' suffix
\r
98 > b) searches the given text only in the related headers (hiding the
\r
99 > difference between "incoming" and "outgoing" messages,
\r
101 This should be configurable, because --output=sender is much faster than
\r
102 --output=recipients. I think that ideal address completion should offer
\r
103 you the addresses you have already written to, i.e.
\r
105 notmuch address --output=recipient from:my@address to:"prefix*"
\r
107 But this may be too slow on non-SSD disks. Some users may therefore prefer
\r
109 notmuch address --output=sender to:my@address from:"prefix*"
\r
111 which would be faster, but also includes every spammer/robot/... who
\r
112 sends anything to you.
\r
115 > considering the body at all)
\r
117 What considers body now?
\r
120 > c) avoids the "bug"/"feature" explained above
\r
122 Yes, if you know the substring you are looking for, implementing a
\r
123 filter would be trivial.
\r
125 > What do you think?
\r
127 Another question is that uses may want to select which my@address to
\r
128 use. So maybe you can add --my-address option that allow specifying one
\r
129 or more addresses. If this option would not be given, all configured
\r
130 addresses in .notmuch-config would be used.
\r
132 So I think that --complete should just construct the query containing
\r
133 from:/to: terms and this should be concatenated with what user specified
\r
134 as a query. For example:
\r
136 notmuch address --complete prefix tag:attachment
\r