What I require of a text editor

The Modest Requirements of a Humble Programmer

As a programmer, I approach a text editor first as a tool for editing programs. A text editor that is ideal for me, then, may not be ideal for those who are not programmers, or who have different tastes. However, I also require a collaborative text editor: a tool which allows me to work with a remote colleague on a challenging bug, or work through a pedagogical problem with a partner just as easily as if we were in the same room, and a tool so convenient that even if we were in the same room we would prefer to use it rather than try to collaborate in a traditional text editor.

This requirement leads to another: anyone I might collaborate with must find the text editor I use to be a productive and enjoyable tool.

Traditional text editors are tools used by an individual, and sharing and collaboration occurs by other means. Once the text editing tool itself becomes a collaborative enviroment, however, it is no longer sufficient for a text editor to satisfy only a subset of users. The text editor I require, then, is one that appeals not only to me and not only to programmers, but to anyone who might use a text editor at all. What follows are my current thoughts on what this entails.


Any particular keybindings or user interface conventions, however thoughtfully designed, will be disliked by some, so these features must be fully customizable.

Expert users of existing editors are much more productive in their editor of choice than in an unfamiliar editor. The ideal editor, then, must be flexible enough to emulate any existing editor to the satisfaction of such a user. Such emulation modes must be easy enough to find and turn on that anyone who would make use of them will not overlook them.

Customizability is no substitute for carefully chosen defaults. The editor must also be usable without customization to as many as possible. The initial settings then, should be those familiar conventions of Notepad or of plain text boxes in typical operating systems.

While Notepad is easy enough for novices, those who use a text editor for hours every day will appreciate and benefit from more advanced features, even if they take some time to learn. An optimal editor would not demand this choice between ease of adoption and ease of use, but would present to the user a path of gentle ascending steps, from the most basic and familiar configuration to the most efficient, by allowing more powerful features to be enabled one by one.

The ideal editor must be fun to learn and use.


To be accessible to all users, the text editor may have different modes optimized for different means of access. A visually rich text editor using HTML5's canvas element would be appropriate for some users, but only if there are other modes available which expose the same information and functionality to those for whom canvas is not accessible.

Collaboration and the Web

The editor I require must make all of my texts available to me from any computer with a Web browser and an Internet connection.

It must allow me to collaborate on the same text in real time with other users who may be geographically remote, so long as they also have access to the Web.

Since Internet access is not always available, the editor must also fully support offline editing. This implies a text editor that is accessible over the Web (without precluding other interfaces), and that texts should be stored both locally on the user's machine and remotely on a Web server.


I expect an editor to preserve all my false starts, accidents, mistakes, and intermediate attempts, not only the final result. No product of human effort may be thrown away simply because a 'save' command was not explicitly given.

The entire history of editing, back to the empty document, including all branches, must be available for review and even alteration. The history must be suitable for answering questions such as "How heavily edited is this document?", "How many people contributed to this text?", "Who wrote the majority of these words?", "Who last edited this line?", or "What paragraphs did I change when I last worked on this paper, and when was that?".

The editor must allow undo of any part of the history, even out of order when that makes sense. It must allow fluid, natural, and powerful interaction with the history of the text, e.g. undoing all edits by a particular person, or between two particular dates. Editing the history should be nearly as easy as editing the text. Editing the history ought not to destroy the true history but extend it; even edits to the history must allow undo.


The editor must always parse the text. An appropriate grammar for the text must be identified, using heuristics when necessary. A syntax tree must be continuously updated throughout the editing process, and made available to editor features such as grammar, spelling, and punctuation aids, when editing natural languages, and syntax highlighting, autocompletion, and compiler integration, when editing programs.

Making use of the syntactic structure of the text, the editor must provide structural editing commands operating at the levels of paragraphs, sentences, formulas, or functions, not merely on lines and characters. The editor must not be a mere blunt instrument for pushing characters here and there, but should make use of advances in computational linguistics to get as close as possible to understanding the text as the author understands it. Features for improving the editor's capacity to understand edited texts should be emphasized, and the editor should be designed to continuously learn from its users about various natural and artificial languages.


Keybinding configurations, user interface themes, parsers and recognizers, optional features, and all that is customizable, extensible, or reprogrammable should be shared over the Web. The editor and those who develop it should encourage the creation of new features by users, including those without programming expertise. This implies well-documented, readily available code, and the use of domain-specific languages to extend the editor's functionality, so that motivated individuals may contribute as easily as possible.


The ideal editor must exist. If in conflict with any other desired feature, the requirement for running code must supervene. Features which would delay the editor's release should be cut ruthlessly in favor of releasing a small core allowing further extension.


The editor must be available to everyone who has access to reasonably modern computer equipment. The editor must be free to use. This also implies light resource usage and cross-platform operation.


The editor must be developed in such a way that its ongoing, active development is assured so long as there are interested users. Any single point of control that could potentially kill future development of the editor would be incompatible with this goal. This implies at least that forking must be allowed and that the code must be available.


The benefit of a collaborative editor is greatest when those who would collaborate are already using it. Therefore the ideal editor should aim to be the most widely used text editor. This implies an ongoing effort to eradicate all barriers to adoption.


In the interests of availability, longevity, and ubiquity, I believe the editor must be released under a permissive free software license.

  1. Mihai Bazon

    How about Emacs? ;-) It's very available, has a history of 30 years, it's totally programmable and customizable, has a horde of editing modes for whatever kind of programming language you can imagine, can edit remote files, and it's pretty light nowadays, compared to monster IDSs such as Eclipse. I would be amazed if there aren't some collaboration features already created. ;-)

    And, something similar is now available on the Web: www.ymacs.org ;-)


    1. inimino

      I consider Emacs to be one of the best editors around, but still wholly inadequate.

      My complaints, roughly in order of the requirements I described in the post:

      - I personally hate the keybindings, and I suspect they contribute to RSI. This may be purely an aesthetic issue, but the vi shortcuts suit my taste and the Emacs keybindings simply do not. Yes, I know there are ways to work around that, but the larger Emacs ecosystem assumes you will be using the default keybindings, and doing otherwise carries a cost.

      - Also on the subject of UI, Emacs is not approachable and does not have a gentle learning curve from "Notepad-mode" through to power user. "Anyone I might collaborate with must find the text editor I use to be a productive and enjoyable tool" sets a high bar which Emacs does not meet.

      - It doesn't meet my requirements for collaboration. If I am editing a buffer in Emacs and want to collaborate on that file in real-time, my best bet is to copy and paste it into Etherpad or something like it. That's probably not going to change anytime soon since many other people don't even have Emacs installed. Web browsers on the other hand are ubiquitous.

      - Emacs doesn't meet my requirements for saving history. Of course this can be done with an external revision control system such as git, which I use, but I see no reason why this should not be something my editor takes care of for me, silently and continuously.

      - Emacs has some excellent parsing facilities; in particular James Clark's nxml-mode makes working with XML almost tolerable, and is the main reason I still use Emacs for some tasks.

      - Emacs is not quite as ubiquitous as I would like, though of course it is fairly popular amongst programmers, particularly among experts. Something that works in a browser would be much more convenient.

      Emacs meets my other requirements (participation, existence, availability, accessibility (with Emacspeak in particular this is quite excellent), longevity, and licensing). Unfortunately, bringing Emacs up to the rest of my requirements seems to me to be more trouble than starting over.

      Ymacs, on the other hand, looks promising.

      1. Mihai Bazon

        — "I personally hate the keybindings, and I suspect they contribute to RSI"

        I love the key bindings, actually, but indeed they probably contribute to RSI (having random pains in my wrists myself). However, I think this happens because I'm extremely productive and manage to press a lot of keys — it's probably true that a tool that makes you work slower will not *seem* to contribute to RSI, but working with a keyboard 10 hours a day for 20 years will unavoidably lead to that, even if you're on Notepad...

        — "Emacs is not approachable and does not have a gentle learning curve from "Notepad-mode" through to power user."

        Not sure why you think that.. The one thing that beginners don't find obvious is how to exit (when they start Emacs in a console). Other than this, you can use Emacs just like you use Notepad, and there's no need to learn anything unless you want to become more productive.

        My wife wrote a 80 paper thesis in Emacs after only about 30 minutes of training from my side. She reckoned, in the end, that it would have taken a lot more time, and the result would have been uglier, if she did that with Open Office.

        — "«Anyone I might collaborate with must find the text editor I use to be a productive and enjoyable tool» sets a high bar which Emacs does not meet."

        Expecting that everyone else will be able to use a tool as well as you can only mean two things: (1) you think everyone is as smart (or as dumb) as you are, or (2) that tool is the lowest common denominator. You shouldn't wish for any of these. If a tool is great, and if you can use it, then by all means use it and don't wait for it to gain popularity. History shows us that the greatest tools are not popular, and this includes programming languages, operating systems and of course, editors.

        — "It doesn't meet my requirements for collaboration. If I am editing a buffer in Emacs and want to collaborate on that file in real-time, my best bet is to copy and paste it into Etherpad or something like it."

        I'm working on something like that for Ymacs, actually. :-) But I'm pretty sure that there should be a similar add-on for Emacs.. Probably not popular, though. ;-) I'll look for it.

        Anyway, thanks for your reply! :)


        1. inimino


          It's been my experience that vi's keybindings are as fast to use as Emacs', but they seem better from an RSI perspective because of the reduced use of chords. Anyway, I don't want to have to choose a tool based on whether or not I happen to like the keybindings or not. I want the tool to conform to my preferences, not the other way around.


          Notepad doesn't have any unnecessary features, and for beginners that is a feature. Emacs is intimidating and has a lot of modes. It requires more experience and skill to use a table saw than a table knife, but we are just talking about bits here; there is no reason we should have to choose between power and approachability. Ideally 'notepad mode' would be the default, and features would be added only when the user wants to add them.

          For people who don't write code for a living or who aren't writing an 80-page thesis, learning Emacs is simply not worth the added power it brings, and it's a shame that we have to have to classes of tool instead of just a range of modes to accommodate different users. Imagine if we had different browsers with incompatible UIs for power users and normal people.

          "A productive and enjoyable tool":

          "Expecting that everyone else will be able to use a tool as well as you [...]"

          I actually don't expect that at all, which is why the above is so important. What I require is that the tool be useful and approachable to all, regardless of their level of expertise.

          At each stage in your use of the tool, you should be able to put in, say, 5 minutes learning a new feature, and get a return on investment of your time as you use that feature. Depending on how frequently you use a text editor, you can learn the features that help you and ignore the rest. There should always be a gentle slope up in terms of choosing to spend more time learning the tool or choosing to just get work done with what you already know. Emacs and vi are like scaling a cliff in this respect.

          Collaborative features:

          I'm glad to hear your working on this for Ymacs and will look forward to seeing what you come up with!