From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 9DE4C431FAE for ; Sat, 16 Jan 2010 11:11:03 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599] autolearn=unavailable Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EftOxBwgkvL7 for ; Sat, 16 Jan 2010 11:11:03 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by olra.theworths.org (Postfix) with ESMTP id CA28D431FBC for ; Sat, 16 Jan 2010 11:11:02 -0800 (PST) Received: by ewy7 with SMTP id 7so2025686ewy.30 for ; Sat, 16 Jan 2010 11:11:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=bbbVhnLXMFzunBzzSEwyyMQ1lv/wSuDcnWgND2nfQhA=; b=JGe52hwzeFaXsXgurW3zuqlIOShcf3YQs8WegZ+uqA0nVOkegjnakOW40A+EI+wli9 tTPZVwM4i6TTynGetJe6YVfshdULbJGZOjlAP/bw5gy70YJNa45u+Z2rq+fh5e+OHYBt GlYYWlKYJP3vDflAMAVEKmI1OdBpyCfj9Bisc= 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= Received: by 10.213.24.24 with SMTP id t24mr1445993ebb.16.1263669060784; Sat, 16 Jan 2010 11:11:00 -0800 (PST) Received: from harikalardiyari ([78.179.49.34]) by mx.google.com with ESMTPS id 5sm4067831eyh.32.2010.01.16.11.10.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 16 Jan 2010 11:10:57 -0800 (PST) Sender: Ali Polatel Date: Sat, 16 Jan 2010 21:10:55 +0200 From: Ali Polatel To: Carl Worth 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 , notmuch@notmuchmail.org Subject: Re: Thoughts on notmuch and Lua X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 19:11:03 -0000 --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 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--