dc/cdaa1dd46ed808450738e164b7a1ef2e711b60

   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 2395A431FBC\r
   6         for <notmuch@notmuchmail.org>; Thu, 14 Jan 2010 15:00:13 -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.826\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1.8, AWL=-0.027, 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 HhJ+aqoY1Q9B; Thu, 14 Jan 2010 15:00:12 -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 42771431FAE;\r
  18         Thu, 14 Jan 2010 15:00:12 -0800 (PST)\r
  19 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  20         id B0ED9550090; Thu, 14 Jan 2010 15:00:11 -0800 (PST)\r
  21 From: Carl Worth <cworth@cworth.org>\r
  22 To: Ali Polatel <alip@exherbo.org>, notmuch@notmuchmail.org\r
  23 In-Reply-To: <20100114084713.GA22273@harikalardiyari>\r
  24 References: <20100114084713.GA22273@harikalardiyari>\r
  25 Date: Thu, 14 Jan 2010 15:00:11 -0800\r
  26 Message-ID: <87eilse1hg.fsf@yoom.home.cworth.org>\r
  27 MIME-Version: 1.0\r
  28 Content-Type: multipart/signed; boundary="=-=-=";\r
  29         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  30 Subject: Re: [notmuch] Thoughts on notmuch and Lua\r
  31 X-BeenThere: notmuch@notmuchmail.org\r
  32 X-Mailman-Version: 2.1.13\r
  33 Precedence: list\r
  34 List-Id: "Use and development of the notmuch mail system."\r
  35         <notmuch.notmuchmail.org>\r
  36 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  37         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  38 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  39 List-Post: <mailto:notmuch@notmuchmail.org>\r
  40 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  41 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  42         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  43 X-List-Received-Date: Thu, 14 Jan 2010 23:00:13 -0000\r
  44 \r
  45 --=-=-=\r
  46 Content-Transfer-Encoding: quoted-printable\r
  47 \r
  48 On Thu, 14 Jan 2010 10:47:13 +0200, Ali Polatel <alip@exherbo.org> wrote:\r
  49 > Before trying to implement anything I decided to send a mail to the list\r
  50 > to ask people's opinion.\r
  51 \r
  52 Hi Ali, welcome to notmuch!\r
  53 \r
  54 I appreciate you soliciting opinions, but I hope that my answer won't\r
  55 discourage you. By all means, please feel free to experiment!\r
  56 \r
  57 > What's the problem?\r
  58 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\r
  59 > Notmuch isn't very configurable.\r
  60 \r
  61 I'll grant that. And as can be seen in TODO and in code comments, we\r
  62 definitely want to fix that.\r
  63 \r
  64 > 1. Configuration file:\r
  65 > The configuration file can be a Lua script that allows more dynamic\r
  66 > configuration. Here's an example:\r
  67 >=20\r
  68 > # notmuch configuration file:\r
  69 > config =3D {}\r
  70 > config.dbpath =3D "/path/to/maildir"\r
  71 > config.exclude =3D function (maildir)\r
  72 >     return not string.match(maildir, ".*Trash.*")\r
  73 >     end\r
  74 > ...\r
  75 \r
  76 That doesn't look very compelling to me.\r
  77 \r
  78 I'd much rather have:\r
  79 \r
  80         [database]\r
  81         path=3D/home/cworth/mail\r
  82         maildir_exclude=3D.*Trash.*\r
  83 \r
  84 with the exact same functionality.\r
  85 \r
  86 Granted, having a full programming language in the configuration file\r
  87 makes thing much more dynamic, but it also makes it much harder for the\r
  88 user to read, edit, and ensure the syntax is correct.\r
  89 \r
  90 > 2. Hooks:\r
  91 > This is a feature I really miss having switched from sup.\r
  92 > There can be many hooks, a hook that formats search output,\r
  93 > a hook that is called before adding messages to the database which may\r
  94 > be used to add initial tags depending on headers etc.\r
  95 \r
  96 I understand that some people really like their hooks. They let users\r
  97 invent all kinds of interesting, custom functionality.\r
  98 \r
  99 But I think hooks also have problems. Sometimes the most interesting\r
 100 functionality has to be pieced together by every user going to a wiki\r
 101 page and finding the "standard" hooks. I'd much rather avoid that by\r
 102 getting the most useful functionality into the program in the first\r
 103 place.\r
 104 \r
 105 Hooks also impose a particular amount of maintenance burden on the\r
 106 software. And they are often implemented in a way that makes them very\r
 107 hard to be discovered.\r
 108 \r
 109 I wrote a message to the sup mailing list describing some of these\r
 110 issues. The context there was a patch I wrote adding a configuration\r
 111 option, (and the sup maintainer preferring it be added as a patch\r
 112 instead):\r
 113 \r
 114         id:1254417826-sup-6584@yoom.home.cworth.org\r
 115         Subject: Re: [sup-talk] [PATCH] Add new :crypto_default configuration opti=\r
 116 on.\r
 117 \r
 118 I did find out later that the sup hooks were more self-documenting than\r
 119 I had understood. (There was a sup command-line option that printed\r
 120 documentation for all available hooks.) Something like that is\r
 121 definitely a requirement for providing hooks.\r
 122 \r
 123 So I'm not entirely opposed to the idea of adding hooks to notmuch, but\r
 124 I'll definitely need to be convinced that any particular functionality\r
 125 can't be better integrated without the hook.\r
 126 \r
 127 > Why Lua?\r
 128 > =3D=3D=3D=3D=3D=3D=3D=3D\r
 129 > Lua has many advantages over other scripting languages when it comes to\r
 130 > integration with a C program. It has a very clean and easy C API, the\r
 131 > overhead of running Lua scripts is not noticable among other things.\r
 132 \r
 133 I've definitely heard lots of good things about "lua embedability". So\r
 134 if we do decide to provide hooks, then lua would seem like a logical\r
 135 option to look at first. I've never looked at it closely myself though.\r
 136 \r
 137 =2DCarl\r
 138 \r
 139 --=-=-=\r
 140 Content-Type: application/pgp-signature\r
 141 \r
 142 -----BEGIN PGP SIGNATURE-----\r
 143 Version: GnuPG v1.4.10 (GNU/Linux)\r
 144 \r
 145 iD8DBQFLT6H76JDdNq8qSWgRAqLiAJ9FP/qv9rH5LvViHc6750+YgN3pzwCfQsr2\r
 146 SsNcr6O9lIPwckTWcj8ovNE=\r
 147 =RPdg\r
 148 -----END PGP SIGNATURE-----\r
 149 --=-=-=--\r