If I wrote a text editor

A little while ago Jezen Thomas linked a video to me on twitter (non-twitter link). It’s a talk by Gary Bernhardt of Destroy All Software. Please go watch it… now. The following post may contain spoilers that could ruin an otherwise excellent talk.

So after that big tableflip inducing reveal, it got me thinking (just like thousands of others who had the same thought), how would I build a text editor. I love my editor, I cherish and nurture it inside it’s own cultivated repository, perfecting it in any way I can. My Vim is just that, mine, nobody else can use it in the same way I couldn’t be effective with my colleagues configuration (probably). Our editors are as much of a project as the projects we’re using them on.

Some think this notion of constantly working on your editor instead of just building things is ludicrous, which is perfectly fine. There are editors and IDEs out there that work perfectly well, but for some of us, that one key combo that doesn’t quite feel right, or that slightly strange indentation in that one edge case is just unacceptable. We need a platform upon which to build our environment. A beautifully simple text editor that we can turn into our very own code editor. They’re all slightly different and they’re all unique. I assume every seasoned Vim (or Emacs!) user would consider their setup as more of a glove than a tool that you grip.

But I want more

If I ever have to type text in anything other than Vim I’m usually unhappy about it. No modes, no Ctrl-W to erase the last word that I completely screwed up, I’m on my own. After watching the aforementioned video however, it made me yearn for even more power and control, something I think Emacs may be able to give me, but with (what I consider to be) a slightly clunky Lisp and way too many features. The package management makes me shy away from Emacs too, especially when compared to tools such as vim-plug. I just find Vim more elegant and focussed on the job of editing text, but it lacks flexibility. Sure there’s some cool plugins out there, and I’ve written a couple, but they’re hard to build, test and maintain. There are a few elite developers churning out masterpieces, but the bar is too high for most to contribute their good ideas. Everything has always seemed pretty hacky to me.

So the only obvious solution would be to devote years of my life to building my own. This is an insane commitment and I may never even begin, but I just wanted to write up and really think about how I would do it either for future reference or so someone else can take those ideas and build it for me.


This is key. It should open to a blank, or almost blank buffer with little to guide you. This is your perfectly honed tool that you’ve been using for years, eight hours a day, you don’t need to be told how to get started. It was probably the first line in the readme. The UI should be simple text based buffers, like a terminal but rendered outside of it to allow fonts and colours beyond the capabilities of your average shell. It is still text based for consistency and easy of plugin development, but it breaks free of the terminals limitations.


Just like Vim, modes such as normal, visual (line and block) and insert are essential. Maybe there can be modes that run alongside or atop each other (like Emacs). Maybe you can have an infinite stack of them that you can pop and push to as you fly through the syntax constructs. It needs modes, and there are hundreds of ways you could take the concepts from Vim (modal like normal) and Emacs (modes like org-mode) and combine them to create something entirely new and exciting.

Some form of shell

It would possibly contain some kind of terminal emulator which could be built and extended with even more of the editors host language. Just like eshell in Emacs. Use iTerm or xfce4-term if you want the full thing, this would be built to run, monitor and integrate tasks, not provide a full environment. Now that would be true wheel reinvention.

Easily extensible

I would like it to be written in a beautiful language such as Clojure as well as extended with it. Forget a plugin framework as such, let the plugins be written in the language of the tool and manipulate the tool directly. They’re essentially lazy loaded modules that have complete control over the platform. They can cause it to do things that was originally thought impossible during the initial implementation. No trying to get patches into the core or hacking around with things that don’t quite give you that value you need. You should have full unrestricted access to every part of the system. We’re using it to write code, so when we change our editor we should be able to change every aspect.

The core modules should probably be implemented through this loading system too with some sort of loading priority. WordPress got some things wrong, but it also got a lot very right, the way you can hook in and rip things out of the underlying infrastructure as it boots is fantastic. WordPress gives you almost total control as a plugin or theme developer. If the core editor with all of its modes was loaded in this way, someone could stop it from loading (or simply disable it at runtime) and replace it with their own implementation. This gives complete control without nasty, albeit rather clever, hacks.

Imagine, for example, unhooking the underlying syntax engine and replacing it with an identical C implementation for performance simply by installing a plugin. That would be amazing. Your editor then becomes a tiny platform with a few default modules that turn it into a little editor. You then add or build everything you need. Much like a kit car, this would take time and effort, but the result is something you essentially built and you’re proud of. For enthusiasts of text editors, such as myself, this should be an exciting prospect.


Nobody would use this, even if I built it and executed it perfectly. Well, nobody would use it any time soon at least. I would need to turn it into either an attractive side project for others to build their environment on top of or create enough tooling myself that people can jump right in. Worst case scenario: I’d get to see just how hard it is to write a good text editor. But I’d learn a hell of a lot along the way.

So that’s about all I have so far. I’ll probably jot down ideas as they come to me, but I would really like to build this, or part of it, over the course of 2015. I think it would be a fun project regardless of the outcome.

  • I mostly share your vision, but I would ditch modes. I understand you find modes useful, but to me the most important thing about software is discoverability and modes are hard to master unless you were born during the 60s. I liked the other features about aneditor though.

    • I certainly wasn’t born anywhere near the 60s, yet they feel like a natural way to edit things now. I think the main attraction for me is that I can make use of the entire keyboard with mnemonic bindings without resorting to holding down random modifier keys all of the time.

      One of the main things that puts me off emacs is the lack of modes being integrated at every level. Evil is okay, but doesn’t change the historical bindings. Some of the “C-x C-something then a number” bindings go way over my head. Whereas gf, *g*o to *f*ile sits very well in my memory.

      I’m also planning some sort of graph explorer for modes and bindings to help document how your own editor is set up. So I’m going to have to respectfully disagree with your opinion, I don’t expect any tool to be immediately usable. I’d rather a very steep learning curve that just keeps going as opposed to a shallow one I can start with instantly. That’s just my preference though.

      I guess I just like the mastery aspect, something that has a huge pay off after a lot of investment. I want something that is simple with regards to it’s fundamental rules, but not in the sense that anyone can pick it up in minutes.

      • If you can start instantly, it means you can start focusing on what matters. I am not very convinced about that huge pay off either. Going up that steep curve will gain you a lot of insight and teach you many valuable things (good enough reason to dabble with editors if you are so inclined), but the editor is not the most important aspect of programming and I would rather create something that has the power we are looking, but without the learning curve.

        • I see what you mean, thank you for the insight. I’ve certainly learnt a lot on my path through Vim over the last few years. I just can’t envisage something with a lot of mappings *not* being modal in some way. Insert mode is only a single key away, it would be possible to start there and to drop into modes to perform expressive changes with minimal keystrokes.

          I should really spend a few months in emacs without the Evil / Vim modal bindings to see another long standing editor from another perspective.

          • I wrote this a year ago, and now I read it again and I kind of sound too pushy! I apologize for trying to cram my world view into your world canvas. I still prefer bindings, but I’ve come to appreciate vim a lot more.