As Magit exemplified, I like the Emacs UX. I consider this a user interface paradigm on the same level as UNIX pipes:
One engine for one editor
Pipes give you a 1D-read-only stream of characters that excels at batch processing. Emacs is all about interactive mutable 2D buffers of attributed text.
Today I realized that an important feature of Emacs text buffers is read-only characters (manual).
Like any editor, you can mark the entire Emacs buffer as read-only. But you can also mark individual substrings as read-only, so you can edit anywhere except specific ranges.
This is a useful feature for bidirectional interaction. Consider the in-editor terminal I’m currently using, which looks like this:
./zig/zig build fuzz -- message_bus
= time: 3s =
info(fuzz): Fuzz seed = 2355780251053186744
info(message_bus_fuzz): command weight: reserved = 0
info(message_bus_fuzz): command weight: ping = 0
info(message_bus_fuzz): command weight: pong = 0
info(message_bus_fuzz): command weight: ping_client = 0
info(message_bus_fuzz): command weight: pong_client = 0
info(message_bus_fuzz): command weight: request = 0
info(message_bus_fuzz): command weight: prepare = 37
info(message_bus_fuzz): command weight: prepare_ok = 0
The first line is the command to execute, it’s typed in manually by me, and then I press the “Submit” shortcut to actually run the command. This is followed by the status line, which shows how long the command has been running so far and the exit code (when the command terminates). The position line is determined by the “Terminal” itself. Finally, the output of the command itself is updated live.
In this type of interface, commands can be modified by the user, but are read-only for the editor. The situation is the opposite – the editor updates it every second, but the user should be prevented from touching it. And the output can be edited CRDT-style by both parties (I often find it useful to edit the output before pasting it elsewhere).
Sadly in VS Code I can’t prevent the user from editing the state, so my implementation is a bit risky, and I think this is the root of why I don’t see VS Code as a great platform for the kind of interactive tools I want to write.
It’s hard to implement read-only categories! Text editing hates you the same way, but this feature requires intelligently tracking text attributes under modifications (see sticky properties), and
Too Feeds back into the modifications themselves! It’s no surprise that VS Code’s built-in editor engine Monaco lost this capability at some point.
Still, I feel like “Does it support the sticky-only feature?” This is a good litmus test to check whether an editor can seamlessly support interactive applications a la Magitte. ever used M-xWell, it echoed M-x Minibuffer has read-only!