In the weeks leading up toe linux.conf.au 2016 I approached edlib development as a sprint. I wanted to put together sufficient functionality so that I could present my LCA2016 talk using slides displayed by edlib. I achieved this goal but at some cost. A lot of the development that went into that sprint was fairly hackish and not well thought out. It achieved the immediate goal but wasn’t good long term development.
With that cost came benefits. Not just working code but a clearer perspective on what I needed to do and what problems would be faced by creating a slide-presentation mode. I don’t regret the sprint at all but it certainly didn’t result in completed work. I had to go over all of that development and turn the prototype into well designed code. This naturally took quite a bit longer but resulted in much more coherent designs and a stronger overall structure. This is done now and my LCA2016 presentation is now in my mainline of edlib development and works well.
There were a number of structural changes that I made while revising all this functionality, I’ll just address a few of them here.
Documents have a clearer identity
Documents need to appear in various display hierarchies where they appear on panes for editing, and they must also exist in a list-of-all-documents. Previously the distinction between these two locations was not very clear – the same sort of object existed in both and just behaved a little differently.
Now we have two different sorts of things: documents which are well defined panes that each access precisely one document, and document access panes which appear in the display hierarchy and contains a reference to the main document pane. Previously these referred to the document itself, now they refer to the pane which owns the document. This has made some implementation details cleaner and hopefully will be easier to think about and work with.
The *Documents* document is now pluggable
The “*Document*” document lists all known documents. Previously it was implemented in core code by what can best be described as a hack: Documents were the children of the focus of the root.
Now when documents are created they call a well known command name. Any module can register a handler for this name and so become the document manager. That module can collect all new documents together, provide a document which presents a list of known documents etc. If you don’t like the module that I have created, you can make your own and plug it in.
Events always travel up the tree towards the root
Previously there was common code for events to be sent to the “focus” pane or the pane containing a given x,y co-ordinate. That is all simplified now and the common code just moved from a leaf towards the root. For those few cases where it is necessary to find the focus or location-based window that must be open coded. As there are about one each of these, this is a simplification.
There is still a bit of ugliness here. When we have a stack of windows that together perform some task it is sometime useful to find the leaf-most window of the stack. This is not a problem for handling keystrokes as the command ‘focus’ will be the leaf-most pane. However in other cases, particular when handling a “Refresh” the leaf-most pane is not immediately known and it must be found.
This is not particular hard to do but the current implementation seems a bit clumsy. I’m wondering if I need to have a specific concept of a “stack of panes” where it is always easy to find the leaf-mode end of the stack. Maybe some idea will come to me.
Next steps
While there is always lots to do there are two particular goals that I am aiming at now that the LCA2016 presentation mode is working.
One goal is to be able to use edlib as a day-to-day editor. This requires at least auto-save and quite a collection of fairly simple functions. Half of the task here is identifying what functionality I really need and the other half is implementing it.
The second goal is to build an email reader based on notmuch. I have lots of ideas for this but there are lots of details to work out and they will require improvements to core functionality.
What I really need is more “long service leave” to work on this, but I don’t get any more of that for several years.
As always, code is available at https://github.com/neilbrown/edlib
