65/5811a082155d1119f26fa41d14077e8b5f7bb4

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id BC08F431FBC\r
   6         for <notmuch@notmuchmail.org>; Fri, 15 Jan 2010 15:15:14 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.834\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1.8, AWL=-0.035, BAYES_50=0.001] autolearn=ham\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id R58DNNwZVe0R; Fri, 15 Jan 2010 15:15:13 -0800 (PST)\r
  16 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  17         by olra.theworths.org (Postfix) with ESMTP id CE51C431FAE;\r
  18         Fri, 15 Jan 2010 15:15:13 -0800 (PST)\r
  19 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  20         id 876B1254091; Fri, 15 Jan 2010 15:15:13 -0800 (PST)\r
  21 From: Carl Worth <cworth@cworth.org>\r
  22 To: Ali Polatel <alip@exherbo.org>\r
  23 In-Reply-To: <20100115210934.GA12515@harikalardiyari>\r
  24 References: <20100114084713.GA22273@harikalardiyari>\r
  25         <87eilse1hg.fsf@yoom.home.cworth.org>\r
  26         <20100115001600.GD25209@lapse.rw.madduck.net>\r
  27         <87vdf3cd1y.fsf@yoom.home.cworth.org>\r
  28         <20100115210934.GA12515@harikalardiyari>\r
  29 Date: Fri, 15 Jan 2010 15:15:13 -0800\r
  30 Message-ID: <87r5prc64e.fsf@yoom.home.cworth.org>\r
  31 MIME-Version: 1.0\r
  32 Content-Type: multipart/signed; boundary="=-=-=";\r
  33         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  34 Cc: martin f krafft <madduck@madduck.net>, notmuch@notmuchmail.org\r
  35 Subject: Re: [notmuch] Thoughts on notmuch and Lua\r
  36 X-BeenThere: notmuch@notmuchmail.org\r
  37 X-Mailman-Version: 2.1.13\r
  38 Precedence: list\r
  39 List-Id: "Use and development of the notmuch mail system."\r
  40         <notmuch.notmuchmail.org>\r
  41 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  42         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  43 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  44 List-Post: <mailto:notmuch@notmuchmail.org>\r
  45 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  46 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  47         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  48 X-List-Received-Date: Fri, 15 Jan 2010 23:15:14 -0000\r
  49 \r
  50 --=-=-=\r
  51 Content-Type: text/plain; charset=utf-8\r
  52 Content-Transfer-Encoding: quoted-printable\r
  53 \r
  54 On Fri, 15 Jan 2010 23:09:34 +0200, Ali Polatel <alip@exherbo.org> wrote:\r
  55 > Carl Worth yazm=C4=B1=C5=9F:\r
  56 > > What do you think, Ali? Would an approach like that satisfy the things\r
  57 > > you had in mind for hooks?\r
  58 >=20\r
  59 > It might, here are some thoughts and questions to help you elaborate:\r
  60 >=20\r
  61 > - How will these scripts manipulate data?\r
  62 >   e.g.: A "tagger" script may get the new mail from stdin and print out\r
  63 >   the new tags which notmuch will read and apply to the message.\r
  64 \r
  65 This can happen with current notmuch entirely with no real "hook"\r
  66 support.\r
  67 \r
  68 We've talked about switching from default tags of "inbox" and "unread"\r
  69 to simply having new mail tagged with a "new" tag. So a "tagger" script\r
  70 could operate simply by doing a "notmuch search" for messages with the\r
  71 "new" tag and could iterate over the filenames to process actual\r
  72 messages. (We don't have support now for emitting just filenames from a\r
  73 "notmuch search", but we have patches for that, and I'll be applying one\r
  74 soon.)\r
  75 \r
  76 So that's a taste for the "scriptability" I see in the current notmuch\r
  77 system that makes it really much more flexible than any "hooks"\r
  78 system. Additional flexibility comes from:\r
  79 \r
  80   * User can run a script like this at any point---not merely when\r
  81     messages are added.\r
  82 \r
  83   * User script isn't restricted to dealing only with "new" messages,\r
  84     but can act on any set of messages based on any search constraint,\r
  85     (or even all messages in the database).\r
  86 \r
  87 The results can then be applied by simply calling "notmuch tag" as\r
  88 needed.\r
  89 \r
  90 And if there are any performance problems there we can fix them, (such\r
  91 as, perhaps we'll end up wanting this script to be able to invoke a\r
  92 single process for all of its tagging rather than calling "notmuch tag"\r
  93 over and over).\r
  94 \r
  95 >   A "search-filter" script may get search results from stdin and filter\r
  96 >   them. Just my initial thoughts.\r
  97 \r
  98 And how would this search functionality and filtering be different than\r
  99 the search functionality provided by notmuch itself?\r
 100 \r
 101 I can think of at least a couple of ways it might be different:\r
 102 \r
 103   1. It would be nice to be able to filter based on tags that are\r
 104      present in a thread, though perhaps not present in any message\r
 105      matching the original search.\r
 106 \r
 107      An obvious application of this is the "thread muting" feature,\r
 108      where once a message is tagged as "muted", no messages delivered to\r
 109      that thread in the future will appear in the inbox.\r
 110 \r
 111      This is a feature I'd like to put into the core of notmuch such\r
 112      that one passes a query to match messages and then also a second\r
 113      query to filter based on the collected tags in threads. Something\r
 114      like:\r
 115 \r
 116         notmuch search tag:inbox --filter=3D"not tag:muted"\r
 117 \r
 118  2. There are other details available at the thread level that are not\r
 119     available at the level at which message-based searching happens.\r
 120 \r
 121     A simple example of this would be the ability to search for threads\r
 122     with a single message, (perhaps checking to ensure that all requests\r
 123     had gotten at least one reply). But one can imagine more complex\r
 124     things as well, "Show me all threads where ImportantPerson sent a\r
 125     message and where I never replied in the thread."\r
 126 \r
 127     For this kind of thing, I think we simply want to build on the\r
 128     output of "notmuch search". The current output isn't very usable for\r
 129     this, but with things like the structured json output, etc. (which,\r
 130     again, I hope to be merging soon), it would be quite easy to write\r
 131     new tools that accept that output and provide additional searching\r
 132     and filtering, etc. And that tool could provide lua-based scripting\r
 133     or whatever else is desired.\r
 134 \r
 135 So my feeling is that if anything can live outside of notmuch, then it\r
 136 should, and should simply build on top of notmuch output. (And we should\r
 137 fix notmuch output to support that well.)\r
 138 \r
 139 And anything that must live within notmuch (or is best supported there),\r
 140 we should see if we can't just make that a core part of notmuch itself,\r
 141 (such as the --filter option I showed above).\r
 142 \r
 143 I'm *still* not wanting to squelch any experimentation with embedding\r
 144 scripting languages inside notmuch, or anything else. I'm just still not\r
 145 seeing anything that requires this.\r
 146 \r
 147 Look at the amount of emacs-lisp code we've written, for example, and\r
 148 the various things it does, (hiding away citations, etc.). That's all\r
 149 "scripting code", but that sits easily on top of the existing notmuch\r
 150 command-line tool.\r
 151 \r
 152 I think I'd prefer to keep that nice clean boundary until we find\r
 153 something that really requires changing that. But, show me something\r
 154 really cool that requires it, and you might convince me. :-)\r
 155 \r
 156 =2DCarl\r
 157 \r
 158 --=-=-=\r
 159 Content-Type: application/pgp-signature\r
 160 \r
 161 -----BEGIN PGP SIGNATURE-----\r
 162 Version: GnuPG v1.4.10 (GNU/Linux)\r
 163 \r
 164 iD8DBQFLUPcB6JDdNq8qSWgRAq9+AJ4mYkws5MIneL+lWDulpBoYtee42ACfUtcX\r
 165 aVYJYbpcpBSoFzky90Y0vuA=\r
 166 =DTyj\r
 167 -----END PGP SIGNATURE-----\r
 168 --=-=-=--\r