1 Return-Path: <ccx@te2000.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 94247429E28
\r
6 for <notmuch@notmuchmail.org>; Sat, 25 Jun 2011 02:32:39 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=1.274 tagged_above=-999 required=5
\r
12 tests=[RDNS_NONE=1.274] 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 LOeDAjGgMX4p for <notmuch@notmuchmail.org>;
\r
16 Sat, 25 Jun 2011 02:32:37 -0700 (PDT)
\r
17 Received: from asterix.te2000.cz (unknown [213.29.225.26])
\r
18 by olra.theworths.org (Postfix) with ESMTP id 25EFC431FD0
\r
19 for <notmuch@notmuchmail.org>; Sat, 25 Jun 2011 02:32:37 -0700 (PDT)
\r
20 Received: from dorje.inet.te2000 (unknown [192.168.1.205])
\r
21 by asterix.te2000.cz (Postfix) with SMTP id 0923D26C8B;
\r
22 Sat, 25 Jun 2011 11:32:34 +0200 (CEST)
\r
23 Received: by dorje.inet.te2000 (sSMTP sendmail emulation);
\r
24 Sat, 25 Jun 2011 11:32:33 +0200
\r
26 Date: Sat, 25 Jun 2011 11:32:33 +0200
\r
27 To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org
\r
28 Subject: Re: Notmuch scripts
\r
29 Message-ID: <20110625093233.GA19267@dorje.inet.te2000>
\r
30 References: <20110624112820.GA26201@dorje.inet.te2000>
\r
31 <8762nvccce.fsf@yoom.home.cworth.org>
\r
33 Content-Type: multipart/signed; micalg=pgp-sha1;
\r
34 protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ"
\r
35 Content-Disposition: inline
\r
36 In-Reply-To: <8762nvccce.fsf@yoom.home.cworth.org>
\r
37 User-Agent: Mutt/1.5.21 (2010-09-15)
\r
38 X-Mailman-Approved-At: Tue, 28 Jun 2011 10:59:27 -0700
\r
39 X-BeenThere: notmuch@notmuchmail.org
\r
40 X-Mailman-Version: 2.1.13
\r
42 List-Id: "Use and development of the notmuch mail system."
\r
43 <notmuch.notmuchmail.org>
\r
44 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
45 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
46 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
47 List-Post: <mailto:notmuch@notmuchmail.org>
\r
48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
49 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
50 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
51 X-List-Received-Date: Sat, 25 Jun 2011 09:32:39 -0000
\r
55 Content-Type: text/plain; charset=utf-8
\r
56 Content-Disposition: inline
\r
57 Content-Transfer-Encoding: quoted-printable
\r
59 On Fri, Jun 24, 2011 at 11:29:21AM -0700, Carl Worth wrote:
\r
60 > So much of the new functionality here consists of things I'd love to
\r
61 > have implemented in the core command-line interface of notmuch
\r
63 That's what I thought. I think it's actually beneficial to go the
\r
64 prototyping route here and start with implementations that can be
\r
65 written and altered quickly.
\r
67 > The features I see that I'd really like to see in the core notmuch
\r
68 > command-line tool are:
\r
70 > * Configurable "saved searches", (a syntax for expanding aliases
\r
71 > for often-repeated search specifications).
\r
73 > That's an idea we've had for a while. What's new with the
\r
74 > zmuch implementation is the proposal of ":alias" for the
\r
75 > syntax. I think I might like that quite a bit. It looks a bit
\r
76 > easier to read (and type) than the previously-proposed
\r
79 Glad you like it. :-)
\r
81 > * Delivery of search results to a maildir of symlinks
\r
83 > The zmuch implementation has this functionality intertwined
\r
84 > with something that also invokes mutt. Obviously, people using
\r
85 > other MUAs might like to access this feature independently.
\r
87 That's one of reasons I'm rewriting it. What I'm planning to have is:
\r
89 * notmuch-maildir-create -- make the symlinks, also save metadata in
\r
92 * notmuch-maildir-merge -- reflect the changes on the original files
\r
94 * notmuch-maildir-refresh -- merge and recreate with same query
\r
96 * notmuch-maildir-mua -- create temp directory, invoke MUA (mutt) on
\r
99 * notmuch-maildir-search -- merge if old maildir is there, prompt for
\r
100 query, create new maildir
\r
102 The last one should be sufficient replacement for what notmuch-mutt
\r
103 currently does, provided one has set up to run merge after mutt instance
\r
104 exits. I'm not very satisfied with naming on the last two, so
\r
105 suggestions are welcome :-)
\r
107 > * Operations on files matching search terms (move, remove,
\r
110 > This isn't an operation I'd previously considered including in
\r
111 > notmuch, but it does seem generally quite useful.
\r
113 These are just handy shorthands, the actual command could still fit on
\r
116 > Should we consider doing something like git does and allow
\r
117 > something like "notmuch xargs" simply find and invoke a shell
\r
118 > script named notmuch-xargs?
\r
120 I thought of that also, but I wouldn't do that yet. Not until the
\r
121 scripts are bit more polished and tested.
\r
123 > Doing that could let us get a bunch of this functionality in
\r
124 > place in the "core" sooner than if we waited for it to be
\r
125 > re-implemented in C.
\r
127 > Though if we did this, I think I'd be highly inclined to port
\r
128 > the scripts from zsh to bash or even POSIX sh. How hard would
\r
131 Not much of a problem for simpler scripts, but for the big ones like
\r
132 saved searches or maildir merging it would mean a lot of added
\r
133 boilerplate. That would reduce the readability and defeat the purpose of
\r
136 I could rewrite the more complex ones in python, but on the other hand,
\r
137 the zsh package is just 6MiB here including debugging symbols. I don't
\r
138 think there will be many who will find it problematic to install.
\r
140 > * Better date syntax for search specifications
\r
142 > That's something that's obviously been missing from notmuch
\r
143 > core from the beginning. And there have been several proposals
\r
144 > with patches to do this in various ways.
\r
146 I think it would be neat to steal this from the 'at' command.
\r
147 By the way, this is another use-case for notmuch proxy.
\r
149 > * Implicit concatenation of search terms with OR
\r
151 > This seems like something easy to do with a command-line
\r
152 > arguemnt. Perhaps "notmuch search --or ..." ?
\r
154 What would I personally like would be to use [] to mean the same as (),
\r
155 just with implicit ORs inside. For example: "[ foo bar ( spam eggs ) ]"
\r
156 would expand to "foo or bar or ( spam and eggs )". This way we can have
\r
157 long sequences of both ORs and ANDs in one query.
\r
160 > If we got all that into the core, then what would be left here would be:
\r
162 > notmuch-mailvars.sh
\r
165 > These would provide integration of notmuch with mutt.
\r
167 Actually I wish to make it generic enough that it can be used with
\r
168 anything that can read a maildir.
\r
171 > notmuch-unspam.sh
\r
173 > These would provide integration of notmuch with
\r
174 > bsfilter, (and perhaps should be named to make that more
\r
175 > clear---or generalized to justify the current name).
\r
177 I'd love to make it generic, that's why I asked what people use.
\r
181 > I haven't looked at this to see what the colorization
\r
182 > actually looks like, (I'm not always a huge fan of lots
\r
183 > of color in my terminals). It seems that this would be
\r
184 > more cleanly implemented as notmuch-colorize.sh or so
\r
185 > and leave the pagination separate.
\r
187 Actually I would like to have some common configuration somewhere, so
\r
188 people can attach colors to certain tags and any app would be able to
\r
191 By the way the flags for less I use make it behave like it was not there
\r
192 at all if the contents fits on one screen or the output is not a
\r
195 > If we had that, I'd feel really comfortable having each of those in
\r
196 > contrib. I think contrib should be restricted to things which provide
\r
197 > integration of notmuch with some external tool, (and should make that
\r
198 > obvious by having a name like notmuch-<tool> or notmuch-<tool>.sh or
\r
201 I think contrib can serve also for experimental extensions and
\r
202 interfaces, unless you want to move them somewhere else.
\r
204 > All in all, there's definitely some very interesting functionality here,
\r
205 > and I definitely appreciate you sharing it. Let's figure out the best
\r
206 > way to get it all integrated into notmuch.
\r
208 Thanks. I'm gonna alter most of the scripts so they better match unix
\r
209 conventions and probably even make manpages for them. So don't take the
\r
210 current state of the repo as final, I just wanted to give you heads up.
\r
212 > Maybe in the meantime we throw everything into contrib even if some of
\r
213 > it is seen as just proposals for better interfaces in the core tool? I
\r
216 That's what I plan to do.
\r
218 > > * Every application that does not act as a proxy should use
\r
219 > > environment variable NOTMUCH to find the actual notmuch executable.
\r
221 > > * Every application that acts as a proxy should ignore the NOTMUCH
\r
224 > That sounds reasonable enough to me. Perhaps these rules could go into a
\r
225 > new contrib/README that would set out some guidelines for writing
\r
226 > contrib tools, (such as notmuch-<tool> which I mentioned above).
\r
228 Great. Should I write that too? :-)=20
\r
230 > > Configuration and temporary files:
\r
231 > > I like XDG specification.
\r
233 > I'm missing some context to know what you're suggesting here.
\r
235 > > I think it's bit unnecessary to have to have
\r
236 > > config files that belong only to few scripts littered all around my
\r
239 > We should be able to put configuration for contrib tools into the main
\r
240 > notmuch configuration file. If your tools don't want to read that file
\r
241 > directly, they should be able to get by with the interfaces provided by
\r
242 > "notmuch config set" and "notmuch config get". Obviously, each tool
\r
243 > should create its own section in the configuration file.
\r
245 I'm not so sure INI format is a good choice for every tool. It's not
\r
246 conveniently parseable by a shell script and sometimes you need more
\r
247 than just get/set functions. For example for saved searches I don't know
\r
248 the key names beforehand and I need to retrieve them in defined order.
\r
250 > Is that an insane plan?
\r
251 I think nice thing to have common configuration. I'm unsure this one
\r
252 size fits all approach is the best way, but I'm kind of okay with it.
\r
254 > > * Spam filter. Do you guys use any? What does it's interface look lik=
\r
256 > > I currently use bsfilter which I've found does it's job pretty
\r
259 > I've currently got amavis and spamassassin adding extra headers, (and
\r
260 > below a certain threshold I've got maildrop delivering detected spam to
\r
261 > a separate maildir).
\r
263 bsfilter can add headers too, though I don't use that feature now. I
\r
264 didn't know how would offlineimap or any other mail-sync solution behave
\r
265 if I went around changing actual content of the messages.
\r
267 > Currently, notmuch never sees the detected spam. Ever since we got
\r
268 > folder: support I've been meaning to let notmuch see it so that I can
\r
269 > use notmuch to dig into my spam when I suspect something got
\r
272 > I don't currently have any system for getting user-provided feedback
\r
273 > into my spam filtering. Do you get that with bsfilter?
\r
275 Yes, bsfilter is short for bayesian filter, so it kind of needs sets of
\r
276 ham and spam messages to learn from. That's why I have the scripts to
\r
279 > > * Colors. I use bright fg on dark bg, but I understand somebody won't
\r
280 > > be happy with this choice.
\r
282 > I'm pretty-much black-on-white only. I really want a similar experience
\r
283 > with my computer that I get from books. (Though I'm still waiting for
\r
284 > much better contrast from my computer displays=E2=80=94e-ink definitely h=
\r
286 > lot for the very static use cases).
\r
288 You'd definitely wouldn't like my cyan for unseen messages then. :-)
\r
289 That's why I'd like to get that in globally configurable, see above on
\r
292 > > * New message processing. Currently I check for spam and I mute
\r
293 > > selected threads. I can see this can be made quite configurable.
\r
294 > > Maybe create procmail equivalent for notmuch? :-)
\r
296 > I think lots of us have various hand-written scripts that call out to
\r
297 > "notmuch tag" a bunch. It's definitely a common idiom to have "notmuch
\r
298 > new" add a new tag, have the new-mail-processing script operate on
\r
299 > tag:new, and then have that script remove tag:new from the things it
\r
302 I actually don't do much tagging, as saved searches seem more flexible
\r
303 to me. The current implementation does three things (apart from having
\r
304 nice progress meter):
\r
305 * applies 'sent' tag to emails from addresses in your config file.
\r
306 This can be accomplished by saved searches too, bot it was more
\r
307 convenient to me to implement it here.
\r
308 * runs spam check on the mail
\r
309 * makes 'mute' tag span whole threads
\r
311 The last thing is not that easy to do in pure shell script.
\r
313 I'm not sure if some domain-specific language would be that big
\r
314 improvement over status quo, that it would be worth implementing.
\r
315 It would be first necessary to asses which features are useful and what
\r
316 people need. Apart from what it currently does I do think that it would
\r
317 be useful if it could move messages around .
\r
319 > An alternative approach has been proposed to make "notmuch new" able to
\r
320 > act on specified messages, (and accept an explicit list of tags to
\r
321 > add). That would make it much easier to actually use existing tools like
\r
322 > procmail directly with notmuch. Some people are currently using the
\r
323 > notmuch-deliver.sh script in use cases like this. (And that script is
\r
324 > another existing candidate for contrib.)
\r
326 I am actually considering using something like that together with
\r
327 dovecot on my server, I want to get some experience with using notmuch
\r
330 Thanks for your elaborate response. :-)
\r
333 Content-Type: application/pgp-signature
\r
335 -----BEGIN PGP SIGNATURE-----
\r
336 Version: GnuPG v2.0.17 (GNU/Linux)
\r
338 iEYEARECAAYFAk4FqzEACgkQq2Q0xnrW+pm8eACeLM/8Wo2oVjuFNyWIHXRHK2SK
\r
339 EYAAoJM//r6joehi7iHYKVIX8dHqKfER
\r
341 -----END PGP SIGNATURE-----
\r
343 --mP3DRpeJDSE+ciuQ--
\r
projects / notmuch-archives.git / blob