About Archive Tags RSS Feed


First binary release of lumail

30 May 2013 21:50

Give me a few days and I'll stop writing about Lumail, but tomorrow I intend to make the first stable source & binary release. From that point onwards you'll not need to track the github repository to getu pdates.

The website has had an overhaul in advance of the release, but could still benefit from a logo. As usual I've written the website using my templer static-site generator. I hacked up a couple of plugins to make it easy to generate the pages of Lua primitive documentation, and handle cross-links suitably. (The source is available for reference.)

The first binary release of the mail-client is obviously something of a big deal. I've been using the client daily for the past week or so, as a read-only mail-viewer. But now that the compose() and reply() primitives are present it is usable "for real". Having real scripting present is also allowing me to do interesting things, which are kinda/sorta demonstrated on the examples page.

Now its a case of fixing up a couple of display-related glitches, and implementing things that are both missing and desirable. Happily the list of missing things is actually surprisingly small.

I think the biggest outstanding issue is that the defaults are Steve-friendly, for example the colour-setup should probably be configurable.

Beyond the personal-defaults I think the next biggest issue is the lack of threading support. Messages are displayed in oldest->newest order. Always.

The other omission is that it is impossible to tag-things, in the mutt-sense, so you can't reply to two messages at once. That's a design decision I might have to revisit. The balance of course is that you can open multiple folders at once, and that rocks!

Happy days.



Comments on this entry

icon Charles Darke at 17:15 on 31 May 2013

Does lumail take care of possible race conditions? e.g. new mail arriving after count_messages() function which could mess up the message index?

-- Mark all messages in the currently selected folder(s) as read.
function mark_all_read()
count = count_messages()
i = 0

while( i < count ) do
jump_index_to( i )
i = i + 1

icon Steve Kemp at 17:22 on 31 May 2013

This is a single threaded application so the code is either displaying messages, etc, or running the lua-code.

On that basis I'm pretty confident there are no obvious races in this kind of code.

icon Andreas Reuleaux at 13:30 on 1 June 2013

While you seem to be happy with your choice of lua, and I certainly don't want
to disturb your comfort, and moreover I only have some experience using lua as
a config language for the awesome window manager (rather than programming in lua
in one of my own projects), I found it interesting, that awhile ago, Julien Danjou,
the creator of awesome, has blogged about the shortcomings of lua, and that
he would not use lua again, but rather some lisp:


I have no idea, if his critisism would still hold today, or if lua has meanwhile
improved, but following Julien's blogs, he seems to be learning/using


Well, he contributes to emacs as well, maybe that can explain his prefs.

Just my two cents, haven't had a chance yet to try lumail, which sounds like
a great idea to me however, but certainly will.

icon Steve Kemp at 11:27 on 3 June 2013

Thus far I've been completely happy with Lua, but I can certainly appreciate the drawbacks - things like the #length primitive, etc, are real problems that I can see would cause pain.

But for the use I'm putting the language to so far I've not found any problems:

  • Defining configuration settings.
  • Defining functions that are called on events.

I could have gotten by with a simple home-grown language, but I think that I've made the right call in choosing something that has been debugged and tested by others.

I'm already being surprised by the interesting things I can do, and I don't expect that to go away.