That was my starting point, and I changed because it wasn’t easier.

I switched because my Emacs config was thousands of lines of code to try to wrangle it to do what I wanted. My editor is ~3.5k lines of code and is closer to things how I want them. It’s spartan, and you and most other people would hate it. That’s fine - I have no interest in writing a general-purpose editor.

Writing a good general-purpose editor is immensely hard, but writing a small editor for yourself is not.

I could absolutely manage to squeeze everything I want into any open-source editor and many proprietary ones via extensions, but there’s no value in that to me when I can write less code and get something that’s exactly adapted to my workflow.

For starters, I use a tiling window manager, and there are no editors that are designed with that in mind. That doesn’t mean they work badly with them, but that e.g. they spent a lot of code on window and tab/frame management that my window manager is already doing the way I want it, and so just by making my editor client-server (a few dozen lines of code with Ruby via DrB), I got that “for free”: When I split a view in two, I use the API of my window manager to halve the size of the actual top level window and insert a new editor instance that observes the same buffer. I could retrofit that on other editors too, but doing it from scratch means the “split a view in two” code in my editor is about a dozen lines of code.

Another example is that for my novels, the syntax highlighting dynamically adapts to highlight things I’ve taken notes about (e.g. characters, locations). I could do that with another editor too, but having full control over the way the rendering layer works meant it was trivial to have my custom workflow control the lexing.