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

[notmuch-archives.git] / f3 / 44a387e770f3891582af66b0ff71abe66012df

Return-Path: <polatel@gmail.com>\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 9DE4C431FAE\r
        for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 11:11:03 -0800 (PST)\r
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
X-Spam-Flag: NO\r
X-Spam-Score: -1.781\r
X-Spam-Level: \r
X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=0.818,\r
        BAYES_00=-2.599] autolearn=unavailable\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 EftOxBwgkvL7 for <notmuch@notmuchmail.org>;\r
        Sat, 16 Jan 2010 11:11:03 -0800 (PST)\r
Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com\r
        [209.85.219.215])\r
        by olra.theworths.org (Postfix) with ESMTP id CA28D431FBC\r
        for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 11:11:02 -0800 (PST)\r
Received: by ewy7 with SMTP id 7so2025686ewy.30\r
        for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 11:11:01 -0800 (PST)\r
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
        h=domainkey-signature:received:received:sender:date:from:to:cc\r
        :subject:message-id:references:mime-version:content-type\r
        :content-disposition:in-reply-to:user-agent;\r
        bh=bbbVhnLXMFzunBzzSEwyyMQ1lv/wSuDcnWgND2nfQhA=;\r
        b=JGe52hwzeFaXsXgurW3zuqlIOShcf3YQs8WegZ+uqA0nVOkegjnakOW40A+EI+wli9\r
        tTPZVwM4i6TTynGetJe6YVfshdULbJGZOjlAP/bw5gy70YJNa45u+Z2rq+fh5e+OHYBt\r
        GlYYWlKYJP3vDflAMAVEKmI1OdBpyCfj9Bisc=\r
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
        h=sender:date:from:to:cc:subject:message-id:references:mime-version\r
        :content-type:content-disposition:in-reply-to:user-agent;\r
        b=LzP+KwNN7uS3spflJ6hfuPL0TZ3bIbeI+lSsFYKu/4c4sg4kCkp4KhoYh6TNwnJXI2\r
        KoegMSx/MwLo3W2wUi3MXtzkPN05fwOd2jyvRTKgLU1i7aKVT23rGsv7bDZ1xGGIZqpC\r
        r2NVDyUX8ZEklqORiamFYYjee+D/Rx3R/5fSM=\r
Received: by 10.213.24.24 with SMTP id t24mr1445993ebb.16.1263669060784;\r
        Sat, 16 Jan 2010 11:11:00 -0800 (PST)\r
Received: from harikalardiyari ([78.179.49.34])\r
        by mx.google.com with ESMTPS id 5sm4067831eyh.32.2010.01.16.11.10.57\r
        (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
        Sat, 16 Jan 2010 11:10:57 -0800 (PST)\r
Sender: Ali Polatel <polatel@gmail.com>\r
Date: Sat, 16 Jan 2010 21:10:55 +0200\r
From: Ali Polatel <alip@exherbo.org>\r
To: Carl Worth <cworth@cworth.org>\r
Message-ID: <20100116191055.GB11414@harikalardiyari>\r
References: <20100114084713.GA22273@harikalardiyari>\r
        <87eilse1hg.fsf@yoom.home.cworth.org>\r
        <20100115001600.GD25209@lapse.rw.madduck.net>\r
        <87vdf3cd1y.fsf@yoom.home.cworth.org>\r
        <20100115210934.GA12515@harikalardiyari>\r
        <87r5prc64e.fsf@yoom.home.cworth.org>\r
MIME-Version: 1.0\r
Content-Type: multipart/signed; micalg=pgp-sha1;\r
        protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu"\r
Content-Disposition: inline\r
In-Reply-To: <87r5prc64e.fsf@yoom.home.cworth.org>\r
User-Agent: Mutt/1.5.20 (2009-06-14)\r
Cc: martin f krafft <madduck@madduck.net>, notmuch@notmuchmail.org\r
Subject: Re: [notmuch] Thoughts on notmuch and Lua\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, 16 Jan 2010 19:11:03 -0000\r
\r
\r
--TRYliJ5NKNqkz5bu\r
Content-Type: text/plain; charset=iso-8859-9\r
Content-Disposition: inline\r
Content-Transfer-Encoding: quoted-printable\r
\r
Carl Worth yazm=FD=FE:\r
> On Fri, 15 Jan 2010 23:09:34 +0200, Ali Polatel <alip@exherbo.org> wrote:\r
> > Carl Worth yazm=FD=FE:\r
> > > What do you think, Ali? Would an approach like that satisfy the things\r
> > > you had in mind for hooks?\r
> >=20\r
> > It might, here are some thoughts and questions to help you elaborate:\r
> >=20\r
> > - How will these scripts manipulate data?\r
> >   e.g.: A "tagger" script may get the new mail from stdin and print out\r
> >   the new tags which notmuch will read and apply to the message.\r
>=20\r
> This can happen with current notmuch entirely with no real "hook"\r
> support.\r
>=20\r
> We've talked about switching from default tags of "inbox" and "unread"\r
> to simply having new mail tagged with a "new" tag. So a "tagger" script\r
> could operate simply by doing a "notmuch search" for messages with the\r
> "new" tag and could iterate over the filenames to process actual\r
> messages. (We don't have support now for emitting just filenames from a\r
> "notmuch search", but we have patches for that, and I'll be applying one\r
> soon.)\r
>=20\r
\r
This is one of the reasons I wanted hook support in the beginning.\r
I'm looking forward to seeing this in notmuch.\r
\r
> So that's a taste for the "scriptability" I see in the current notmuch\r
> system that makes it really much more flexible than any "hooks"\r
> system. Additional flexibility comes from:\r
>=20\r
>   * User can run a script like this at any point---not merely when\r
>     messages are added.\r
>=20\r
>   * User script isn't restricted to dealing only with "new" messages,\r
>     but can act on any set of messages based on any search constraint,\r
>     (or even all messages in the database).\r
>=20\r
> The results can then be applied by simply calling "notmuch tag" as\r
> needed.\r
>=20\r
\r
+1. I totally agree.\r
\r
> And if there are any performance problems there we can fix them, (such\r
> as, perhaps we'll end up wanting this script to be able to invoke a\r
> single process for all of its tagging rather than calling "notmuch tag"\r
> over and over).\r
>=20\r
> >   A "search-filter" script may get search results from stdin and filter\r
> >   them. Just my initial thoughts.\r
>=20\r
> And how would this search functionality and filtering be different than\r
> the search functionality provided by notmuch itself?\r
>=20\r
\r
I accept, this search-filter idea is kinda stupid now that I think about\r
it.\r
\r
> I can think of at least a couple of ways it might be different:\r
>=20\r
>   1. It would be nice to be able to filter based on tags that are\r
>      present in a thread, though perhaps not present in any message\r
>      matching the original search.\r
>=20\r
>      An obvious application of this is the "thread muting" feature,\r
>      where once a message is tagged as "muted", no messages delivered to\r
>      that thread in the future will appear in the inbox.\r
>=20\r
>      This is a feature I'd like to put into the core of notmuch such\r
>      that one passes a query to match messages and then also a second\r
>      query to filter based on the collected tags in threads. Something\r
>      like:\r
>=20\r
>       notmuch search tag:inbox --filter=3D"not tag:muted"\r
>=20\r
\r
Looks like a good idea indeed.\r
\r
>  2. There are other details available at the thread level that are not\r
>     available at the level at which message-based searching happens.\r
>=20\r
>     A simple example of this would be the ability to search for threads\r
>     with a single message, (perhaps checking to ensure that all requests\r
>     had gotten at least one reply). But one can imagine more complex\r
>     things as well, "Show me all threads where ImportantPerson sent a\r
>     message and where I never replied in the thread."\r
>=20\r
>     For this kind of thing, I think we simply want to build on the\r
>     output of "notmuch search". The current output isn't very usable for\r
>     this, but with things like the structured json output, etc. (which,\r
>     again, I hope to be merging soon), it would be quite easy to write\r
>     new tools that accept that output and provide additional searching\r
>     and filtering, etc. And that tool could provide lua-based scripting\r
>     or whatever else is desired.\r
>=20\r
\r
Makes sense. Structured output would make things really simpler.\r
\r
> So my feeling is that if anything can live outside of notmuch, then it\r
> should, and should simply build on top of notmuch output. (And we should\r
> fix notmuch output to support that well.)\r
>=20\r
\r
Works for me, as long as it solves my problems and as I stated above I\r
think it will.\r
\r
> And anything that must live within notmuch (or is best supported there),\r
> we should see if we can't just make that a core part of notmuch itself,\r
> (such as the --filter option I showed above).\r
>=20\r
> I'm *still* not wanting to squelch any experimentation with embedding\r
> scripting languages inside notmuch, or anything else. I'm just still not\r
> seeing anything that requires this.\r
>=20\r
> Look at the amount of emacs-lisp code we've written, for example, and\r
> the various things it does, (hiding away citations, etc.). That's all\r
> "scripting code", but that sits easily on top of the existing notmuch\r
> command-line tool.\r
>=20\r
> I think I'd prefer to keep that nice clean boundary until we find\r
> something that really requires changing that. But, show me something\r
> really cool that requires it, and you might convince me. :-)\r
>=20\r
\r
I don't have anything in mind right now but when I do we can talk\r
further :)\r
\r
Thanks for the descriptive response, I really appreciate it.\r
\r
> -Carl\r
\r
--=20\r
Regards,\r
Ali Polatel\r
\r
--TRYliJ5NKNqkz5bu\r
Content-Type: application/pgp-signature\r
Content-Disposition: inline\r
\r
-----BEGIN PGP SIGNATURE-----\r
Version: GnuPG v2.0.14 (GNU/Linux)\r
\r
iEYEABECAAYFAktSDz8ACgkQQU4yORhF8iCI5QCgiWuF3wMh7Ub6t4aTpe2xXlr3\r
MUQAn1UcdvtlOfzHhvPhf4zJjneRKOZL\r
=yI3i\r
-----END PGP SIGNATURE-----\r
\r
--TRYliJ5NKNqkz5bu--\r