I had a brain-wave last week. I thought it would take me about a day to implement but it took 3 to get it working almost reasonably and the rest of the week to polish it and create some proper use-cases to exercise it properly. But that is done now and I am quite happy with the result. It related to the rendering side of edlib.
It been over 3 months - maybe you thought I had given up - but no. I had some holidays and other distractions, but I'm back and will be working fairly consistently for a while.
The topic for today is "Commands". Commands are a standard interface for code in one module of the editor to call code in some other module. Various objects in the editor have commands attached to perform various tasks specific to that object. To some extent you can think of commands like object methods in an object-orient system, but that is only part of the story.
In many cases, commands are associated with names in a key-map. The key maps were hinted at in my previous note about managing input, but they are broader than that and details have changed since last I wrote. So maybe that is a good place to start.
Commands to an editor - at least the sort of editor that edlib is designed for - usually involve single keystrokes or key combinations. Translating those keystrokes, as well as mouse actions, into commands is the topic of this note. Many editors also support commands that are written out with words. Such commands are often introduced with Meta-X in emacs or "colon" in vi. For the purposes of edlib, such interactions can be managed by creating a simple document in a small window somewhere and accepting key-stroke commands to edit that document. Some keystrokes will "complete" the command which will make the window disappear and will perform the required action. So word-based commands are certainly possible, but they happen at a different level.
Displaying the document being edited is, of course, very important for any editor.
I have memories of the first editor I used on Unix which was em, rather than the well known "ed". It actually allowed a single line to be edited "directly" rather than by using pattern substitution (s/pattern/replace/) commands or rewriting whole lines. It also had a 'v' command to view lines of context around the current line. That ability to see what has happening helped a lot.
We've come a long way of course and today we expect to be able to easily see and move around the context of the place we are editing ... though that "context" is usually the very simple "nearby lines of text".
edlib needs to make it easy to provide a display of context, without mandating what that context might look like. To achieve this it provides "displays" and "panes". These are used for directing input from the user to the documents as well as for displaying content from the document to the user, but for now just the latter will be discussed.
I've decided to write an editor. Silly idea I know - there are already two out there: both vim and emacs are quite good. I've heard rumors that there might be others, but investigation always shows they are just toys, not real editors. They don't support reading email, unless that is all that they do.
And I know that I'm supposed to be designing a new language: ocean. And I will... maybe. But how can one write code for a new language without a new editor (though one could equally wonder what language a new editor might be coded in if not a new language...). Ocean will have to wait.
So why a new editor? Well I really love emacs. Really. But I also hate it. I've tried programming in emacs and I just can't manage it. It isn't just the LISP (though that doesn't thrill me), it is the low-level hacking at the attributes in the buffer to create the image that I want to display. It feels like assembly programming. It is probably a personal weakness on my part - other people seem to manage. But isn't it always out of personal weakness that great genius emerges? I'm sure it is.