I use my own editor as my daily editor, both for code and most other text files. A few observations on the article:
> Use it early
This was key to me. If you're going to wait until you have a perfect editor to use it, you're better off spending your time on something else, because it'll take a really long time to get there if you ever do.
I started working on my editor because I was endlessly tinkering with my emacs config and realised I could write an editor in fewer lines than my config...
You need to have a reasonable clear picture of what an MVP looks like to you. But having as a goal to use it early can also drive design.
E.g. in my case the first thing I did to enable this was to have the editor serialise all open buffers to JSON and write a dump regularly. If I didn't expect to use the editor until it was stable, I might not have. But I came to like being able to start the editor after a reboot and have all of my buffers as they were.
I later also moved the buffers into a separate process using DrB (the editor is in Ruby). Combined that made it near impossible to lose changes as DrB makes the backend near crash proof (exceptions are forwarded to the client), and the checkpoints/dumps deals with the last little piece of risk.
The day that was finished, I switched 90%+ of my editing to my own editor even though it was still buggy and lacking in functionality.
As a result I as of writing have 2199 open buffers, some dating back a couple of years. I kill some now and again - e.g. if I open a particularly large file, or something sensitive - but by default I just stopped caring as the dump is only 66MB.
> If you’re using the code editor to write itself, the most pressing bugs and missing features will make themselves apparent to you for free.
This is a big deal with using my own editor. I have a "roadmap" of things I like the idea of, but "what is painful right now" trumps all of it, because I don't have any users (nor do I want any - I'm slowly splitting functionality into gems that I'm happy to deal with issues with, but the github copy of the repo of the editor itself is wildly out of date and heavily dependent on my personal setup, so likely won't even run for anyone else)
It also means I can follow the "refactor when it seems like a good idea" advice without caring if the editor is half broken for a while. I have bugs in there that are clear regressions that I'm ok with working around but that I'd never allow myself to commit code for if I was writing this with the expectation of other people using it.
This is really interesting! Is your editor written is Ruby then? Is the code hosted somewhere public?
I am also curious what advantage you found in putting the buffers in a separate process. Is it just that a crash in the front end doesn’t cause you to loose changes? Why not just save at regular intervals instead? Is the idea to persistent undo or file revisions?
I am also curious what you thought was a limiting factor of Emacs so that you found it easier to write an editor from scratch.
It's on github [1], but the version on github hasn't been pushed to in ages and is a mess because, well, I haven't really cared about making it work for anyone else, so not sure how useful it is to look at. It's an ugly mess, and frankly the one downside of doing a project like this is that it's a bit embarrassing to show people - since I'm the only user I only clean things up when the mess starts hampering me, and since the codebase is so small, that's rare (my current iteration, not the Github one) is about 3.3k, with about 1k of that being syntax-highlighting stuff I'd like to try to get upstreamed to Rouge)
I started out with Femto [2] and ended up quickly gutting it (there's next to nothing left now), and as an example of a minimalist Ruby editor, Femto is perhaps a better starting point - it's certainly both cleaner and smaller.
I've started breaking a bunch of functionality into gems (termcontroller, file_writer, ansiterm, editor_core, keyboard_map) of various stages of usability for others, and my goal is to over time eventually be left with the editor as a tiny shell around reusable components + my personal config, but as per this article, I plod along and fix the things most pressing to me personally and nobody else so who knows when that will happen.
As long as it keeps being useful to me, that's what matters. In that respect it's also a meditative experience of sort that takes my mind off work and having to work in a more professional manner.
> I am also curious what advantage you found in putting the buffers in a separate process. Is it just that a crash in the front end doesn’t cause you to loose changes? Why not just save at regular intervals instead? Is the idea to persistent undo or file revisions?
I also save at regular intervals, so you're right that if that was the only consideration I probably wouldn't have bothered.
But the editor is a terminal application, and I use a tiling window manager (bspwm), and so I figured that if I could spawn another editor instance and have my wm open it in the right space and with access to the same buffer, I didn't need the editor itself to have any understanding of windows itself. Here's "split_vertical" that opens a second view of the same buffer:
def split_vertical(buffer_id)
system("split-vertical 2>/dev/null term -e e --buffer #{buffer_id}")
end
[EDIT: Should also clarify here that "term" is a wrapper for whichever terminal I currently favour, at the moment mlterm, and "e" is an alias for my editor; if I ever were to try to make this usable for anyone else, there'd be a whole lot of cleanups to make - the biggest concession towards this I've made has been to recently move most dependencies on my environment into a separate file]
split-vertical is a helper (I split out a handful of things that depends on external tools) that just runs "bspc node -p south" to get bspwm to halve the height of the current window and "swallow" the next window being opened into the space freed up below the active window, and then exec's its argument. So meta-2/meta-3 works roughly like ctrl-x+2/ctrl-x+3 in Emacs (EDIT: fixed; already forgetting the Emacs keybindings...), except the frames end up in their own windows, running their own client.
Had remoting the buffers been a lot of work, I wouldn't have, but the the Drb specific part of the code is <100 lines and the combined effect of the resilience (if an exception is thrown in the server code, I get thrown into a Pry repl in the client) and the extra abilities it enables makes it worthwhile.
Similarly, I've avoided implementing my own directory handling, and just farmed that out to a wrapper that currently uses rofi, same for theme selection (for syntax highlighting), buffer selection, etc.
The minimalism of delegating all of these things elsewhere appealed to me.
> I am also curious what you thought was a limiting factor of Emacs so that you found it easier to write an editor from scratch.
Strongly disliking Lisp was high on the list (I like the concepts; hate the syntax intensely). Also, it wasn't so much a limiting factor, as realising that my Emacs config file was larger than toy editors I'd played with in the past, and a minimalist bent making it appeal to me to go for something smaller. Also seemed fun (and has been)
> Use it early
This was key to me. If you're going to wait until you have a perfect editor to use it, you're better off spending your time on something else, because it'll take a really long time to get there if you ever do.
I started working on my editor because I was endlessly tinkering with my emacs config and realised I could write an editor in fewer lines than my config...
You need to have a reasonable clear picture of what an MVP looks like to you. But having as a goal to use it early can also drive design.
E.g. in my case the first thing I did to enable this was to have the editor serialise all open buffers to JSON and write a dump regularly. If I didn't expect to use the editor until it was stable, I might not have. But I came to like being able to start the editor after a reboot and have all of my buffers as they were.
I later also moved the buffers into a separate process using DrB (the editor is in Ruby). Combined that made it near impossible to lose changes as DrB makes the backend near crash proof (exceptions are forwarded to the client), and the checkpoints/dumps deals with the last little piece of risk.
The day that was finished, I switched 90%+ of my editing to my own editor even though it was still buggy and lacking in functionality.
As a result I as of writing have 2199 open buffers, some dating back a couple of years. I kill some now and again - e.g. if I open a particularly large file, or something sensitive - but by default I just stopped caring as the dump is only 66MB.
> If you’re using the code editor to write itself, the most pressing bugs and missing features will make themselves apparent to you for free.
This is a big deal with using my own editor. I have a "roadmap" of things I like the idea of, but "what is painful right now" trumps all of it, because I don't have any users (nor do I want any - I'm slowly splitting functionality into gems that I'm happy to deal with issues with, but the github copy of the repo of the editor itself is wildly out of date and heavily dependent on my personal setup, so likely won't even run for anyone else)
It also means I can follow the "refactor when it seems like a good idea" advice without caring if the editor is half broken for a while. I have bugs in there that are clear regressions that I'm ok with working around but that I'd never allow myself to commit code for if I was writing this with the expectation of other people using it.