--- /dev/null
+Return-Path: <ccx@te2000.cz>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 94247429E28\r
+ for <notmuch@notmuchmail.org>; Sat, 25 Jun 2011 02:32:39 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 1.274\r
+X-Spam-Level: *\r
+X-Spam-Status: No, score=1.274 tagged_above=-999 required=5\r
+ tests=[RDNS_NONE=1.274] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id LOeDAjGgMX4p for <notmuch@notmuchmail.org>;\r
+ Sat, 25 Jun 2011 02:32:37 -0700 (PDT)\r
+Received: from asterix.te2000.cz (unknown [213.29.225.26])\r
+ by olra.theworths.org (Postfix) with ESMTP id 25EFC431FD0\r
+ for <notmuch@notmuchmail.org>; Sat, 25 Jun 2011 02:32:37 -0700 (PDT)\r
+Received: from dorje.inet.te2000 (unknown [192.168.1.205])\r
+ by asterix.te2000.cz (Postfix) with SMTP id 0923D26C8B;\r
+ Sat, 25 Jun 2011 11:32:34 +0200 (CEST)\r
+Received: by dorje.inet.te2000 (sSMTP sendmail emulation);\r
+ Sat, 25 Jun 2011 11:32:33 +0200\r
+From: ccx@te2000.cz\r
+Date: Sat, 25 Jun 2011 11:32:33 +0200\r
+To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org\r
+Subject: Re: Notmuch scripts\r
+Message-ID: <20110625093233.GA19267@dorje.inet.te2000>\r
+References: <20110624112820.GA26201@dorje.inet.te2000>\r
+ <8762nvccce.fsf@yoom.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; micalg=pgp-sha1;\r
+ protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ"\r
+Content-Disposition: inline\r
+In-Reply-To: <8762nvccce.fsf@yoom.home.cworth.org>\r
+User-Agent: Mutt/1.5.21 (2010-09-15)\r
+X-Mailman-Approved-At: Tue, 28 Jun 2011 10:59:27 -0700\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sat, 25 Jun 2011 09:32:39 -0000\r
+\r
+\r
+--mP3DRpeJDSE+ciuQ\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Disposition: inline\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Fri, Jun 24, 2011 at 11:29:21AM -0700, Carl Worth wrote:\r
+> So much of the new functionality here consists of things I'd love to\r
+> have implemented in the core command-line interface of notmuch\r
+\r
+That's what I thought. I think it's actually beneficial to go the\r
+prototyping route here and start with implementations that can be\r
+written and altered quickly.\r
+\r
+> The features I see that I'd really like to see in the core notmuch\r
+> command-line tool are:\r
+>=20\r
+> * Configurable "saved searches", (a syntax for expanding aliases\r
+> for often-repeated search specifications).\r
+>=20\r
+> That's an idea we've had for a while. What's new with the\r
+> zmuch implementation is the proposal of ":alias" for the\r
+> syntax. I think I might like that quite a bit. It looks a bit\r
+> easier to read (and type) than the previously-proposed\r
+> "{alias}".\r
+\r
+Glad you like it. :-)\r
+\r
+> * Delivery of search results to a maildir of symlinks\r
+>=20\r
+> The zmuch implementation has this functionality intertwined\r
+> with something that also invokes mutt. Obviously, people using\r
+> other MUAs might like to access this feature independently.\r
+\r
+That's one of reasons I'm rewriting it. What I'm planning to have is:\r
+\r
+ * notmuch-maildir-create -- make the symlinks, also save metadata in\r
+ the maildir\r
+\r
+ * notmuch-maildir-merge -- reflect the changes on the original files\r
+\r
+ * notmuch-maildir-refresh -- merge and recreate with same query\r
+\r
+ * notmuch-maildir-mua -- create temp directory, invoke MUA (mutt) on\r
+ it, merge back\r
+\r
+ * notmuch-maildir-search -- merge if old maildir is there, prompt for\r
+ query, create new maildir\r
+\r
+The last one should be sufficient replacement for what notmuch-mutt\r
+currently does, provided one has set up to run merge after mutt instance\r
+exits. I'm not very satisfied with naming on the last two, so\r
+suggestions are welcome :-)\r
+\r
+> * Operations on files matching search terms (move, remove,\r
+> xargs)\r
+>=20\r
+> This isn't an operation I'd previously considered including in\r
+> notmuch, but it does seem generally quite useful.\r
+\r
+These are just handy shorthands, the actual command could still fit on\r
+one line.\r
+\r
+> Should we consider doing something like git does and allow\r
+> something like "notmuch xargs" simply find and invoke a shell\r
+> script named notmuch-xargs?\r
+\r
+I thought of that also, but I wouldn't do that yet. Not until the\r
+scripts are bit more polished and tested.\r
+\r
+> Doing that could let us get a bunch of this functionality in\r
+> place in the "core" sooner than if we waited for it to be\r
+> re-implemented in C.\r
+>=20\r
+> Though if we did this, I think I'd be highly inclined to port\r
+> the scripts from zsh to bash or even POSIX sh. How hard would\r
+> that be?\r
+\r
+Not much of a problem for simpler scripts, but for the big ones like\r
+saved searches or maildir merging it would mean a lot of added\r
+boilerplate. That would reduce the readability and defeat the purpose of\r
+prototyping.\r
+\r
+I could rewrite the more complex ones in python, but on the other hand,\r
+the zsh package is just 6MiB here including debugging symbols. I don't\r
+think there will be many who will find it problematic to install.\r
+\r
+> * Better date syntax for search specifications\r
+>=20\r
+> That's something that's obviously been missing from notmuch\r
+> core from the beginning. And there have been several proposals\r
+> with patches to do this in various ways.\r
+\r
+I think it would be neat to steal this from the 'at' command.\r
+By the way, this is another use-case for notmuch proxy.\r
+\r
+> * Implicit concatenation of search terms with OR\r
+>=20\r
+> This seems like something easy to do with a command-line\r
+> arguemnt. Perhaps "notmuch search --or ..." ?\r
+\r
+What would I personally like would be to use [] to mean the same as (),\r
+just with implicit ORs inside. For example: "[ foo bar ( spam eggs ) ]"\r
+would expand to "foo or bar or ( spam and eggs )". This way we can have\r
+long sequences of both ORs and ANDs in one query.\r
+\r
+=20\r
+> If we got all that into the core, then what would be left here would be:\r
+>=20\r
+> notmuch-mailvars.sh\r
+> notmuch-mutt.sh\r
+>=20\r
+> These would provide integration of notmuch with mutt.\r
+\r
+Actually I wish to make it generic enough that it can be used with\r
+anything that can read a maildir.\r
+\r
+> notmuch-spam.sh\r
+> notmuch-unspam.sh\r
+>=20\r
+> These would provide integration of notmuch with\r
+> bsfilter, (and perhaps should be named to make that more\r
+> clear---or generalized to justify the current name).\r
+\r
+I'd love to make it generic, that's why I asked what people use.\r
+\r
+> notmuch-pager.sh\r
+>=20\r
+> I haven't looked at this to see what the colorization\r
+> actually looks like, (I'm not always a huge fan of lots\r
+> of color in my terminals). It seems that this would be\r
+> more cleanly implemented as notmuch-colorize.sh or so\r
+> and leave the pagination separate.\r
+\r
+Actually I would like to have some common configuration somewhere, so\r
+people can attach colors to certain tags and any app would be able to\r
+utilize that.\r
+\r
+By the way the flags for less I use make it behave like it was not there\r
+at all if the contents fits on one screen or the output is not a\r
+terminal.\r
+\r
+> If we had that, I'd feel really comfortable having each of those in\r
+> contrib. I think contrib should be restricted to things which provide\r
+> integration of notmuch with some external tool, (and should make that\r
+> obvious by having a name like notmuch-<tool> or notmuch-<tool>.sh or\r
+> whatever).\r
+\r
+I think contrib can serve also for experimental extensions and\r
+interfaces, unless you want to move them somewhere else.\r
+\r
+> All in all, there's definitely some very interesting functionality here,\r
+> and I definitely appreciate you sharing it. Let's figure out the best\r
+> way to get it all integrated into notmuch.\r
+\r
+Thanks. I'm gonna alter most of the scripts so they better match unix\r
+conventions and probably even make manpages for them. So don't take the\r
+current state of the repo as final, I just wanted to give you heads up.\r
+\r
+> Maybe in the meantime we throw everything into contrib even if some of\r
+> it is seen as just proposals for better interfaces in the core tool? I\r
+> don't know.\r
+\r
+That's what I plan to do.\r
+\r
+> > * Every application that does not act as a proxy should use\r
+> > environment variable NOTMUCH to find the actual notmuch executable.\r
+> >=20\r
+> > * Every application that acts as a proxy should ignore the NOTMUCH\r
+> > variable\r
+>=20\r
+> That sounds reasonable enough to me. Perhaps these rules could go into a\r
+> new contrib/README that would set out some guidelines for writing\r
+> contrib tools, (such as notmuch-<tool> which I mentioned above).\r
+\r
+Great. Should I write that too? :-)=20\r
+\r
+> > Configuration and temporary files:\r
+> > I like XDG specification.\r
+>=20\r
+> I'm missing some context to know what you're suggesting here.\r
+>=20\r
+> > I think it's bit unnecessary to have to have\r
+> > config files that belong only to few scripts littered all around my\r
+> > homedir.\r
+>=20\r
+> We should be able to put configuration for contrib tools into the main\r
+> notmuch configuration file. If your tools don't want to read that file\r
+> directly, they should be able to get by with the interfaces provided by\r
+> "notmuch config set" and "notmuch config get". Obviously, each tool\r
+> should create its own section in the configuration file.\r
+\r
+I'm not so sure INI format is a good choice for every tool. It's not\r
+conveniently parseable by a shell script and sometimes you need more\r
+than just get/set functions. For example for saved searches I don't know\r
+the key names beforehand and I need to retrieve them in defined order.\r
+\r
+> Is that an insane plan?\r
+I think nice thing to have common configuration. I'm unsure this one\r
+size fits all approach is the best way, but I'm kind of okay with it.\r
+\r
+> > * Spam filter. Do you guys use any? What does it's interface look lik=\r
+e?\r
+> > I currently use bsfilter which I've found does it's job pretty\r
+> > well.\r
+>=20\r
+> I've currently got amavis and spamassassin adding extra headers, (and\r
+> below a certain threshold I've got maildrop delivering detected spam to\r
+> a separate maildir).\r
+\r
+bsfilter can add headers too, though I don't use that feature now. I\r
+didn't know how would offlineimap or any other mail-sync solution behave\r
+if I went around changing actual content of the messages.\r
+\r
+> Currently, notmuch never sees the detected spam. Ever since we got\r
+> folder: support I've been meaning to let notmuch see it so that I can\r
+> use notmuch to dig into my spam when I suspect something got\r
+> mis-detected.\r
+>=20\r
+> I don't currently have any system for getting user-provided feedback\r
+> into my spam filtering. Do you get that with bsfilter?\r
+\r
+Yes, bsfilter is short for bayesian filter, so it kind of needs sets of\r
+ham and spam messages to learn from. That's why I have the scripts to\r
+handle that.\r
+\r
+> > * Colors. I use bright fg on dark bg, but I understand somebody won't\r
+> > be happy with this choice.\r
+>=20\r
+> I'm pretty-much black-on-white only. I really want a similar experience\r
+> with my computer that I get from books. (Though I'm still waiting for\r
+> much better contrast from my computer displays=E2=80=94e-ink definitely h=\r
+elps a\r
+> lot for the very static use cases).\r
+\r
+You'd definitely wouldn't like my cyan for unseen messages then. :-)\r
+That's why I'd like to get that in globally configurable, see above on\r
+notmuch-pager\r
+\r
+> > * New message processing. Currently I check for spam and I mute\r
+> > selected threads. I can see this can be made quite configurable.\r
+> > Maybe create procmail equivalent for notmuch? :-)\r
+>=20\r
+> I think lots of us have various hand-written scripts that call out to\r
+> "notmuch tag" a bunch. It's definitely a common idiom to have "notmuch\r
+> new" add a new tag, have the new-mail-processing script operate on\r
+> tag:new, and then have that script remove tag:new from the things it\r
+> processed.\r
+\r
+I actually don't do much tagging, as saved searches seem more flexible\r
+to me. The current implementation does three things (apart from having\r
+nice progress meter):\r
+ * applies 'sent' tag to emails from addresses in your config file.\r
+ This can be accomplished by saved searches too, bot it was more\r
+ convenient to me to implement it here.\r
+ * runs spam check on the mail\r
+ * makes 'mute' tag span whole threads\r
+\r
+The last thing is not that easy to do in pure shell script.\r
+\r
+I'm not sure if some domain-specific language would be that big\r
+improvement over status quo, that it would be worth implementing.\r
+It would be first necessary to asses which features are useful and what\r
+people need. Apart from what it currently does I do think that it would\r
+be useful if it could move messages around .\r
+\r
+> An alternative approach has been proposed to make "notmuch new" able to\r
+> act on specified messages, (and accept an explicit list of tags to\r
+> add). That would make it much easier to actually use existing tools like\r
+> procmail directly with notmuch. Some people are currently using the\r
+> notmuch-deliver.sh script in use cases like this. (And that script is\r
+> another existing candidate for contrib.)\r
+\r
+I am actually considering using something like that together with\r
+dovecot on my server, I want to get some experience with using notmuch\r
+first.\r
+\r
+Thanks for your elaborate response. :-)\r
+\r
+--mP3DRpeJDSE+ciuQ\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v2.0.17 (GNU/Linux)\r
+\r
+iEYEARECAAYFAk4FqzEACgkQq2Q0xnrW+pm8eACeLM/8Wo2oVjuFNyWIHXRHK2SK\r
+EYAAoJM//r6joehi7iHYKVIX8dHqKfER\r
+=arH4\r
+-----END PGP SIGNATURE-----\r
+\r
+--mP3DRpeJDSE+ciuQ--\r
projects / notmuch-archives.git / commitdiff