Re: [PATCH v4 01/16] add util/search-path.{c, h} to test for executables in $PATH

[notmuch-archives.git] / ef / 4f6573ce9407c4e43134a488d693d030410f5c

Return-Path: <cworth@cworth.org>\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 8A8E1431FD0\r
        for <notmuch@notmuchmail.org>; Fri, 24 Jun 2011 11:29:29 -0700 (PDT)\r
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
X-Spam-Flag: NO\r
X-Spam-Score: 0\r
X-Spam-Level: \r
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
        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 WO6bWpUe7HEF for <notmuch@notmuchmail.org>;\r
        Fri, 24 Jun 2011 11:29:28 -0700 (PDT)\r
Received: from arlo.cworth.org (arlo.cworth.org [50.43.72.2])\r
        by olra.theworths.org (Postfix) with ESMTP id 9547F431FB6\r
        for <notmuch@notmuchmail.org>; Fri, 24 Jun 2011 11:29:28 -0700 (PDT)\r
Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
        by arlo.cworth.org (Postfix) with ESMTP id 730D729A4FF;\r
        Fri, 24 Jun 2011 11:29:27 -0700 (PDT)\r
Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
        id 633E0254157; Fri, 24 Jun 2011 11:29:27 -0700 (PDT)\r
From: Carl Worth <cworth@cworth.org>\r
To: ccx@te2000.cz, notmuch@notmuchmail.org\r
Subject: Re: Notmuch scripts\r
In-Reply-To: <20110624112820.GA26201@dorje.inet.te2000>\r
References: <20110624112820.GA26201@dorje.inet.te2000>\r
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1\r
        (i486-pc-linux-gnu)\r
Date: Fri, 24 Jun 2011 11:29:21 -0700\r
Message-ID: <8762nvccce.fsf@yoom.home.cworth.org>\r
MIME-Version: 1.0\r
Content-Type: multipart/signed; boundary="=-=-=";\r
        micalg=pgp-sha1; protocol="application/pgp-signature"\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: Fri, 24 Jun 2011 18:29:29 -0000\r
\r
--=-=-=\r
Content-Type: text/plain; charset=utf-8\r
Content-Transfer-Encoding: quoted-printable\r
\r
On Fri, 24 Jun 2011 13:28:21 +0200, ccx@te2000.cz wrote:\r
> As some of you know I have written several scripts that aid using\r
> notmuch, including an alternative to the notmuch-mutt perl script.\r
\r
Thanks for sharing these, Jan!\r
\r
> Since Carl Worth consented to include them into official distribution\r
> I am now cleaning them up, writing docs and extending it so it covers\r
> all features notmuch-mutt currently has.\r
...\r
> Or you can browse the code at:\r
>       http://webprojekty.cz/ccx/loggerhead/zmuch/files\r
\r
It's been interesting for me to read through the README here.\r
\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, (I\r
always have wanted it to be useful for direct command-line interaction\r
by a human). Some of these features I think have even be implemented\r
previously by Austin through his custom query parser.\r
\r
The features I see that I'd really like to see in the core notmuch\r
command-line tool are:\r
\r
        * Configurable "saved searches", (a syntax for expanding aliases\r
          for often-repeated search specifications).\r
\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
        * Delivery of search results to a maildir of symlinks\r
\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
          I think I'd like to see this as:\r
\r
                notmuch search --format=3Dmaildir:/path/to/directory\r
\r
        * Operations on files matching search terms (move, remove,\r
          xargs)\r
\r
          This isn't an operation I'd previously considered including in\r
          notmuch, but it does seem generally quite useful.\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
          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
\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
        * Better date syntax for search specifications\r
\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
        * Implicit concatenation of search terms with OR\r
\r
          This seems like something easy to do with a command-line\r
          arguemnt. Perhaps "notmuch search --or ..." ?\r
\r
If we got all that into the core, then what would be left here would be:\r
\r
        notmuch-mailvars.sh\r
        notmuch-mutt.sh\r
\r
                These would provide integration of notmuch with mutt.\r
\r
        notmuch-spam.sh\r
        notmuch-unspam.sh\r
\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
        notmuch-pager.sh\r
\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
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
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
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
>   * 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
\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
> Configuration and temporary files:\r
> I like XDG specification.\r
\r
I'm missing some context to know what you're suggesting here.\r
\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
\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
Is that an insane plan?\r
\r
>   * Spam filter. Do you guys use any? What does it's interface look like?\r
>     I currently use bsfilter which I've found does it's job pretty\r
>     well.\r
\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
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
\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
>   * Colors. I use bright fg on dark bg, but I understand somebody won't\r
>     be happy with this choice.\r
\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 hel=\r
ps a\r
lot for the very static use cases).\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
\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
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
=2DCarl\r
\r
=2D-=20\r
carl.d.worth@intel.com\r
\r
--=-=-=\r
Content-Type: application/pgp-signature\r
\r
-----BEGIN PGP SIGNATURE-----\r
Version: GnuPG v1.4.11 (GNU/Linux)\r
\r
iEYEARECAAYFAk4E14EACgkQ6JDdNq8qSWhD7wCgg9onbYJXWTFyJp6DQr1Gdbvh\r
pKIAoJDujLvSloL8CzRL7AXtxZVSc4XT\r
=u3I8\r
-----END PGP SIGNATURE-----\r
--=-=-=--\r