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