I’ve been very slack. Sorry. I keep thinking “I should write a blog post about that” when I make some progress with edlib. But I also think “or I could write some more code instead”. I do enjoy writing blog posts. But I seem to enjoy the code more.
Consequently, I’ve lost track of what has happened since my last post. Git tells me that I have made 379 commits since then. I’ve added “Alt-!” to run a shell command, with a history of recent commands stored in a buffer. I’ve provided a way for attributes on text to trigger call-backs to display panes, to enabling highlighting of text; and used this to better display matches for the current search. I’ve broken the “Refresh” event into three separate events, one that updates the sizes of panes, one that can update the position of a document in a pane, and one that redraws the content. And I’ve fixed lots of bugs and cleaned up lots of code. But the big thing that I’ve been working on is a notmuch email client.
Notmuch Email
Notmuch is an email handling tool that maintains an index into a database of email messages, can add and remove tags on messages, and can perform various searches. This makes it quite easy to present a list of email messages which match some criteria, and to extract the individual messages for display. Notmuch comes with an emacs mode which is usable, but far from perfect. So I’m building a notmuch interface in edlib. You can try it by typing “M-x nm enter” providing that you already have notmuch configured to access your email.
The appearance of the notmuch mode that I envision is based largely on claws-mail, though several other email readers have similar appearance. There is a narrow column on the left with the names of folders (saved searches with notmuch). The remainder is divided into a list of message summaries at the top and the body of a message below that. This means having a small number of panes in a fixed relationship with each other. Were an application to try this in emacs it would be easy to setup but hard to maintain. It is too easy for the user to split and close panes which would mess up the arrangement.
In edlib, my approach is to stack a tile-set inside a pane provided by the main tile-set. Each tile set can have a name and split/resize/close commands from the keyboard only go to the primary unnamed tile-set. So if the cursor is in the email-body-view pane and I type “C-x-2” to split the pane, it doesn’t split the body view, but instead splits the whole email application pane. The pane containing my three-part view of email remains as three parts in the same relationship, but the pane as a whole might change size. Currently it only responds by resizing the sub-panes, though I might teach it to hide some sub-panes when the over-all pane gets too small. This shows what the app looks like after splitting the pane.
The arrangement of panes and documents took a little effort to get right, and raises some interesting issues. The primary document represents the whole notmuch database and presents a list of saved-searches. So when you view that with the default viewing pane you get the appearance in the bottom half of the above. When you then select a search, a subordinate document is created which stores just the results of that search. This is stacked on top of a new tile and an appropriate viewer is placed on top of it.
In this arrangement there is now a document with another document as an ancestor in the pane tree. The ‘search’ document is stacked over the tiles. The primary data-base document is stacked under all of these 3 tiles. This leaves room for confusion about the meaning of marks which are passed up or down the stack. I had previously assumed there could only be one document beneath a leaf pane. Now there can be two and so a mark passed down the stack might be mistakenly processed by the wrong document. This should be easy enough to fix as their is already a field in the mark which can be set by the document which own the mark. But it is something I hadn’t foreseen.
There is a lot more work to do on this application. In particular it does not yet allow tags to be set or any other changes to be made, such as creating new saved searches. Also, it only displays email messages as raw text. notmuch can dissect a mime message into the various parts to make them easier to present, but I currently want edlib to do that natively. I imagine a number of different display panes for displaying different types of data, and an RFC-2822 pane which parses the message and attaches display panes over different parts as needed.
So: good progress, but still so much to do…
