Frequently Asked Questions
This page lists questions & answers relating to the project as a whole. There is also a separate technical FAQ available.
- IMAP is new, how does it work?
Because integrating with existing libraries was seen as a large task I've implemented IMAP support by shelling out to perl. This isn't as crazy as it sounds - we only shell out at very specific times:
- On connection to read the list of folders.
- When a new folder is selected we read all the messages.
- When marking a message as new/unread/deleted.
Yes there is overhead, but in practice it is fast enough. If you struggle you might prefer to use imapsync, offlineimap, fetchmail, or similar to sync your mail locally then read it that way.
- How does outgoing mail get sent?
Outgoing mail is sent by executing the command you specify in your configuration file.
Lumail Version Configuration Setting Lumail 2.x Config:set( "global.mailer", "/usr/lib/sendmail -t" ) Lumail Legacy sendmail_path()
- How do I schedule mail-fetching?
The on_idle() documentation has been updated to provide an example of calling your external command to sync mail on a regular schedule.
If mail is delivered directly, via procmail or similar, no such action is required.
- What license is the code released under?
The code is released under the GNU General Public License, version 2 or later.
- How does this client differ from more established clients?
At the moment the client has reached the point where it is complete enough to be used exclusively. There are many differences between this client, and existing ones:
- lumail is a modal client. That is almost unique.
- lumail has a real embedded language for scripting, Lua.
Other differences are, sadly, negative:
- You'll only ever operate on a single message. There is nothing like mutt's tag-prefix command.
- But when coding you can easily write functions that apply to all visible messages, or some subset of them.
- There is no POP3/SMTP support.
- There is no support for MH-H/Mail folders. Just Maildirs.
- Although IMAP is supported.
- Why write another mail client?
For the past few years I've been using mutt-patched, which adds the ability to display a "sidebar". This sidebar allowed the navigation of open folders at almost all times, and the sidebar could be limited to display only folders containing unread mail.
However recently the sidebar patch has lost the ability to see folders only containing unread messages. This initially made me think about re-patching mutt, but later got me thinking about how you'd write and use a truly modal mail client.
As it turns out I tend to focus my mail reading on viewing a list of folders with unread messages, then opening them in turn. Better still would be the ability to open all folders with unread mail - and thus this idea of this client was born.
- Why embed Lua?
The intention is that lumail will be a flexible email client, which means that it must allow things to be configured in ways that I do not expect.
Allowing a client to be configured in interesting ways demands some kind of "scripting", or the ability to set values/options conditionally in the configuration file.
Some clients allow this to be achieved using their own home-grown configuration language, with perhaps a few conditional operators.
Rather than inventing a simple language, spending the time required, it seems so much more natural to pick an existing implementation which is small, easy to learn, and well-documented. On that basis I picked Lua.
- What can I do with Lua?
The configuration file(s) that you load are 100% pure Lua, which has many primitives made available to it.
Using Lua scripting you can define functions, react to events, and write a configuration file that works upon numerous unrelated hosts.
There is a brief Lua examples page showing some of the things that you might wish to do. There are also collections of sample code in source repository - look beneath
sample.lua/to see those.
If you find yourself missing a specific function/primitive/binding you may report that as a bug against the github repository.
- What does it look like?
There is a page of screenshots available to give you some idea.
- I found a bug, what do I do?
First of all thank you for trying the client.
- How can I help?
Bug reports are very useful, whether they relate to missing functionality you'd like to see present (new primitives, etc), or report actual problems you've encountered.
Code contributions, typo-fixes for this website, and similar are equally welcome. I'm happy to give commit access to the main repository to anybody who sends me more than two valid patches.
Finally if you just want to buy me presents that's always nice; though an email saying "This is cool" is just as rewarding.