From: Carl Worth <cworth@cworth.org>
To: Ali Polatel <alip@exherbo.org>, notmuch@notmuchmail.org
In-Reply-To: <20100114084713.GA22273@harikalardiyari>
References: <20100114084713.GA22273@harikalardiyari>
Date: Thu, 14 Jan 2010 15:00:11 -0800
Message-ID: <87eilse1hg.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Subject: Re: [notmuch] Thoughts on notmuch and Lua
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Thu, 14 Jan 2010 10:47:13 +0200, Ali Polatel <alip@exherbo.org> wrote:
> Before trying to implement anything I decided to send a mail to the list
> to ask people's opinion.

Hi Ali, welcome to notmuch!

I appreciate you soliciting opinions, but I hope that my answer won't
discourage you. By all means, please feel free to experiment!

> What's the problem?
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Notmuch isn't very configurable.

I'll grant that. And as can be seen in TODO and in code comments, we
definitely want to fix that.

> 1. Configuration file:
> The configuration file can be a Lua script that allows more dynamic
> configuration. Here's an example:
>=20
> # notmuch configuration file:
> config =3D {}
> config.dbpath =3D "/path/to/maildir"
> config.exclude =3D function (maildir)
>     return not string.match(maildir, ".*Trash.*")
>     end
> ...

That doesn't look very compelling to me.

I'd much rather have:

	[database]
	path=3D/home/cworth/mail
	maildir_exclude=3D.*Trash.*

with the exact same functionality.

Granted, having a full programming language in the configuration file
makes thing much more dynamic, but it also makes it much harder for the
user to read, edit, and ensure the syntax is correct.

> 2. Hooks:
> This is a feature I really miss having switched from sup.
> There can be many hooks, a hook that formats search output,
> a hook that is called before adding messages to the database which may
> be used to add initial tags depending on headers etc.

I understand that some people really like their hooks. They let users
invent all kinds of interesting, custom functionality.

But I think hooks also have problems. Sometimes the most interesting
functionality has to be pieced together by every user going to a wiki
page and finding the "standard" hooks. I'd much rather avoid that by
getting the most useful functionality into the program in the first
place.

Hooks also impose a particular amount of maintenance burden on the
software. And they are often implemented in a way that makes them very
hard to be discovered.

I wrote a message to the sup mailing list describing some of these
issues. The context there was a patch I wrote adding a configuration
option, (and the sup maintainer preferring it be added as a patch
instead):

	id:1254417826-sup-6584@yoom.home.cworth.org
	Subject: Re: [sup-talk] [PATCH] Add new :crypto_default configuration opti=
on.

I did find out later that the sup hooks were more self-documenting than
I had understood. (There was a sup command-line option that printed
documentation for all available hooks.) Something like that is
definitely a requirement for providing hooks.

So I'm not entirely opposed to the idea of adding hooks to notmuch, but
I'll definitely need to be convinced that any particular functionality
can't be better integrated without the hook.

> Why Lua?
> =3D=3D=3D=3D=3D=3D=3D=3D
> Lua has many advantages over other scripting languages when it comes to
> integration with a C program. It has a very clean and easy C API, the
> overhead of running Lua scripts is not noticable among other things.

I've definitely heard lots of good things about "lua embedability". So
if we do decide to provide hooks, then lua would seem like a logical
option to look at first. I've never looked at it closely myself though.

=2DCarl

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFLT6H76JDdNq8qSWgRAqLiAJ9FP/qv9rH5LvViHc6750+YgN3pzwCfQsr2
SsNcr6O9lIPwckTWcj8ovNE=
=RPdg
-----END PGP SIGNATURE-----
--=-=-=--