edlib ideas from elsewhere

There have been a couple of articles on lwn.net (https://lwn.net/Articles/819452/ and https://lwn.net/Articles/832311/) about emacs and how it could be better, which have generated lots of discussion (a really valuable aspect of lwn.net). For some reason this encouraged me to explore more of vim – I’ve never really got passed the basics that I learned in in the late 80’s) and I also stumbled across https://ecc-comp.blogspot.com/2015/05/a-brief-glance-at-how-5-text-editors.html (largely because edlib was mentioned in the hacker-news discussion https://news.ycombinator.com/item?id=11244103). All of this has encouraged me to take a step back and look for a different perspective on some editor issues.

Key combinations

One stand-out issue is the choice of key combinations for editing functions. Emacs use C-w for cut (“wipe”), M-w for copy (wipe-without-removing), and C-y for paste (“yank”). Few other editors use these. The most common keys for these operations are C-x for cut, C-c for copy, and C-v for paste. I don’t personally stumble over any of these, though I do trip up on the difference between C-s (Search for emacs) and C-f (find for everyone else). Many other keys are different, and it isn’t really practical to support both at once — too much overlap.

So maybe it is time for me to cut the cord that binds me so tightly to emacs, and create an edlib mode that uses more common keys. How would that work? The keys I would need (including those above) are:

• C-x for cut
• C-c for copy
• C-v for paste
• C-f for find
• C-g for find-again
• C-z for undo
• C-y for redo

I think that is most of it. Cursor movement uses arrow keys and I think emacs is close enough to what everyone else does there. All of the above keys are already used by emacs, so I’d need to put that functionality elsewhere.

• C-x is a prefix for lots if “eXtended” commands – opening new files, splitting windows, words counts, etc etc. I’m tempted to move these all over to Alt-x. Many of them could reasonable be grouped into a few menus, and I like the ideas that Alt-letter in most cases opens a menu and is a prefix for the commands in that menu. So maybe Alt-f for file/document/buffer related commands. Of course that means Alt-arrow for moving by words rather than Alt-f and Alt-b.
• C-c is a prefix for lots of “Context” commands. “Compile” is the one I use most often but there are lots more. They could go in a context menu using Alt-c …. but then I need a new way to capitalize a word.
• C-v is page-down. Obviously there is a dedicated page-down key, but that I harder to find, especially on my notebook. I don’t have a good answer for that. Maybe I’ll need to teach my fingers to find page-down.
• C-f is forward character. I guess the arrow keys aren’t that hard to find.
• C-g is a general-purpose abort. “Esc” could fill that role, when it isn’t serving as a prefix equivalent to Alt. I think ‘Esc’ by itself should be softer than C-g is. For example, C-g will kill a running compile, if done in the right window. A simple Esc isn’t usually so heavy handed. Maybe Esc-Esc could be a stronger kill.
• C-z will suspend or iconize emacs. This made a lot of sense back when we all used job-control to multiple multiple tasks on the one terminal. Now that we have lots of windows I don’t find job-control interesting, so I disable C-z in emacs because it is too easy to mis-type and does something too heavy-handed for an accident. So using C-z for undo is an easy choice.
• C-y is “yank’, but we’ll be using C-v now, so no loss.
• Alt-x (which I want for C-x) is ‘enter a command”. That could move to Alt-X (shifted) without too much trouble.
• Alt-c is Capitalize, but I might want it for a context menu. Again, may shift Alt-C could do for one of these. Emacs doesn’t make much use for Alt-Shift combinations, so there is a fair bit of wiggle-room there.

After a quick analysis, this does seem like it might work. I’d need to be sure that I’m comfortable using the arrow keys and page-up/down, but maybe I can be comfortable with those. I guess I’ll just have to give it a try.

The document list

I am completely comfortable with the list of active documents being invisible except when I ask for it (C-x C-b). It seems other people aren’t. When I was exploring split-window functionality if vim, one thing that struck me was that the name of every document was always visible – possibly abbreviated. The most abbreviated form was in the tabbed layout where all documents were listed along the top of the window, and you could select one to see the content. One of the commenters on an lwn.net article suggests this was a requirement, not necessarily in that format (possibly a side-bar for navigation around documents). On a related note, emacs has a mode that some prefer which groups the buffers in various ways rather than having a simple least-recently-used list.

I find I have so many documents (buffers) open that listing them all is prohibitive. Grouping them might be useful – certainly demoting auto-generated buffers is a good idea which I don’t think edlib gets quite right yet. I don’t think this is an idea that will change the way I work, but I’ll try to keep it in mind when I’m working in areas that might be affected by these needs.

Undo and redo

The current undo functionality in edlib is closely based on emacs. It is indefinite undo (I don’t currently trim storage at all). A branching tree of changes is stored. So if I edit, undo, edit differently, I can still go back to the second edit. I have no “redo” command, “undo” walks the entire tree in a predictable order. Apparently some people don’t like that, or don’t understand it.

Certainly a number of editors have a “redo” command separate from “undo”. Emacs now has a “tree-undo” mode where “undo” only goes backwards, “redo” is available and goes forwards, and it is possible to explicitly take different branched for redo. You can even visualize the branches somehow. While this doesn’t really appeal to me, I do appreciate that it would be good for the underlying functionality to support the low-level features so that a different interface can easily be built if wanted.

One thing that I haven’t copied from emacs is the option to undo only changes with a selected range. This seems like it might occasionally be useful, but it doesn’t fit my implementation at all. I can go back to any particular point in time, but I cannot easily extract the edits and re-apply them. Maybe I should…

Document storage

This brings me to document storage – there is a whole article about this linked above, though it doesn’t mention undo. My current implementation is somewhat like a rope but with a flat linked list of elements rather than a tree. Other options are certainly possible and might be worth exploring.

The idea of keeping an array of lines, or in some other way treating lines as distinct objects, is interesting. Apparently vi and vim do this. Not everything is line-based of course, but many things are. Having lines makes sorting a lot simpler, so maybe something like this would be useful for a document that wants to sort lines. Fortunately the design of edlib makes it relatively easy to introduce a new storage format along-side or instead of the current one.

I’ve been wondering about sorting directory – and the list of documents – and maybe it would be good to have a generic sortable document type which these can build on. Certainly worth considering when it comes time to sort directories.

Colours, documentation, discoverability, and more.

There are lots of other idea, and one of the reason for writing this note was to keep hold of those links at the top so I can review them latter.

Better control of colours, and ensuring good contrast, is certainly on my list, but I haven’t thought much about it.

In-line documentation is something I’ve been thinking more about. I’d like each DEF_CMD() to include documentation which can easily be extracted and indexed.

I already have the beginnings of discoverability in the command to create a list of all interactive-commands, for A-x command completion. Building on that might prove productive.

There is certainly plenty to do. While I primarily want an editor that works for me, rather than anyone else, I do want to avoid being completely insular. Other people might suggest things that I’ll find useful even though I don’t realize it yet. So I think this has been a valuable exercise, even if it doesn’t lead anywhere concrete yet.