Do you use a Real Editor?

I’m not going to tell you which editor you should use (Emacs). I’m not trying to feed the editor wars (Emacs 4evar!!!!1!!).

I do think that every programmer that cares about productivity should use a Real Editor, though. I’ve thought a lot about what that means. I could easily come up with a list of twenty tests that an editor should pass before it can be deemed a Real Editor. But the list would still be incomplete.

So I came up with a couple of heuristics instead. If your editor satisfies these two requirements, chances are it’s a Real Editor.

  1. You can record a series of edits, save the recording as a macro, edit the macro as a script, and then convert the script into a redistributable editor extension/plugin.
  2. The editor never, ever loses data.

Rule #1 implies a lot about the editor:

  • It has a macro recording facility. If your job description involves editing a lot of structured text, there is a level of productivity that is impossible to achieve without either using an editor with macros, or employing a Virtual Assistant or intern to perform tedious repetitive edits. I don’t use macros every day but when I do, they save me hours of work.
  • It is sufficiently introspective to convert keyboard commands into script statements. An introspective editor is an extensible editor. And an introspective editor is able to tell you about itself and its functions in ways that help you learn to use it better.
  • It has a native scripting language. This is a prerequisite for having a healthy ecosystem of hacks, tweaks, and extensions.

Rule #2 should be a base-level requirement for anyone who is paid money to write code, but surprisingly, a lot of text editors focus on bells & whistles before they focus on the fundamentals. If an editor isn’t mature enough to safeguard your data even in the event of a catastrophic crash, it isn’t ready for production use.

I’m not saying that you have to pick a single editor and use it exclusively. Maybe there is an IDE which doesn’t quite qualify as a Real Editor but it has great refactoring support. But if you have been programming for a few years and you haven’t mastered at least one Real Editor, you are shortchanging yourself and anyone that depends on your output.

So. Are you using a Real Editor?

UPDATE: I’d be interested in getting a list together of all the editors that meet those two requirements. I know for certain that both Emacs and VIM do. I don’t have enough experience with other editors to list any others. Feel free to leave comments suggesting editors that satisfy the two rules.

27 comments

  1. Why yes, I do. It's called Vim and I've heard from trusted sources that it rocks Emacs' world to the point that people have been writing Emacs macros to emulate Vim features, 😀

    But yeah, I agree with both points. I've been a Visual Studio user at the beginning of my career and I can't count how many times it died on me in the middle of editing a code file.

    When I started Rails, I used everything from Komodo Edit to Netbeans, but I've been happiest with Vim.

    1. Emacs is the only editor powerful enough to perfectly emulate inferior editors 😉 All editors will be assimilated into the collective.

      And yes, I just compared my favored editor to the Borg.

  2. I deliberately do not use what you call a “real editor”. I decided long ago that the marginal improvement in productivity I would gain from a more sophisticated editor would not justify the amount of time I would need to invest learning the editor's features or the memory space I would need to dedicate to remembering its shortcuts and quirks.

    I am rather of the opinion that if you are spending most of your time editing code, you are doing it wrong; programming is mostly about thinking, not about writing. Therefore optimizing the text editor is focusing attention on the wrong part of the problem.

    1. Actually Vim has the same idea. That's why it doesn't start in “edition mode”. The Vim philosophy is being in Insert mode (that's the name they give it) the less you can.

      Consider the case where you are not creating code, but debugging. In that scenario “real editors” also shine.

      And finally, there's just not evidence to think our brain have a memory space limit. It is not a real argument. The learning curve on the other hand, I can understand. And yet… you can learn vim one step at a time. It's not a “take it all or it's worthless”. You can start using it as a glorified notepad. You only need to know how to save, quit and change modes (to know how to be in Insert mode).

      Hope this helps

    2. 1) There's the “slow easy” way and the “fast hard” way. By not learning features, you're doing the former.

      2) I think while I write.

      3) Most useful applications involve writing a lot of code.

      4) There are many parts to the “problem” and I can focus on more than one of them.

      1. I erred by describing my workflow in overly general terms. If your work involves a lot of repetitive text manipulation, I can see why you might want to have a scripting/macro language built into your editor.

        I certainly have chosen the “slow easy” way to edit text; my point is that it was a conscious, rational choice. The term “real editor” implies that every other kind of editor is non-real, fake, inadequate, and that every rational person can thus be expected to choose a “real editor” once its benefits have been explained. I disagree; there are many work styles, many kinds of work, and the powerful tools which make one person's life easier are a complicated waste of time for another.

        1. Actually, I don't use macros all that often, I admit. But when I do use them, they save me a lot of time. For example, I do a lot of refactoring, and that can involve making many of the same changes again and again.

          I think “real editor” just means an editor that does all the things that people in general expect from an editor. If you don't need a “real” editor, that just means you're happy with less powerful tools. And reducing such dependencies definitely has its pros.

  3. I agree with #2. As for #1 if you are editing the same thing over and over you are doing it wrong. A decent programming language (Ruby to name one) should allow you to remove 99% of that repetitive crap.

    On the other hand if you are using an inferior language (Java, .NET and PHP to name three) then yes having a editor to make up for the shortcomings of your language is necessary. 🙂

    1. That would be a viable argument if the only thing you ever edit is program code. In the real world, programmers are confronted with XML, HTML, YAML, CSV, and innumerable context-specific DSLs, and occasionally even backward programming languages like Java. A decent programmer doesn't throw up his or her hands when confronted with a non-optimal data format.

      1. In that case my “text editor” is a scripting language. 🙂 Sounds like yours is as well (macro language). Yours is just built-in while mine I run from the command line. 🙂

        1. I'll just paste in what I just said to Mars above, since I think it's applicable:

          I've seen this lead to a lot of wasted time on real world projects. You have the programmers who have mastered neither a scripting language nor a decent editor, who will doggedly make repetitive edits over and over again until finished. And then you have programmers (such as myself) who can't bear the thought of not automating a repetitive task, and will spend two hours tweaking a script to do the task automatically – for a one-off job which they may never repeat again.

          If you've mastered a good editor, instead of being an either/or this becomes a continuum of options. You can record a macro that gets most of the job done, tweak it a little if it fails on some unexpected parts of the file, run it again, touch up whatever is left, and be done before either of the programmers I described above. It's an interactive, iterative process where you work your way to the 80% solution as efficiently as possible. And you're left with something reusable in case you find you need to do something similar (but not quite the same) the next day.

      2. Perhaps this explains some of the difference in our perspectives. I almost never have to deal with any of that stuff, and when I do it's just to look at it or search for something in it. If I did need to transform such data I wouldn't see it as an editing task, but as a coding task, and I'd whip up a little program to do the work for me (as Eric Anderson says below).

        1. I've seen this lead to a lot of wasted time on real world projects. You have the programmers who have mastered neither a scripting language nor a decent editor, who will doggedly make repetitive edits over and over again until finished. And then you have programmers (such as myself) who can't bear the thought of not automating a repetitive task, and will spend two hours tweaking a script to do the task automatically – for a one-off job which they may never repeat again.

          If you've mastered a good editor, instead of being an either/or this becomes a continuum of options. You can record a macro that gets most of the job done, tweak it a little if it fails on some unexpected parts of the file, run it again, touch up whatever is left, and be done before either of the programmers I described above. It's an interactive, iterative process where you work your way to the 80% solution as efficiently as possible. And you're left with something reusable in case you find you need to do something similar (but not quite the same) the next day.

    2. …but anyhow, I think you've missed the point. Rule #1 is a heuristic which, if met, implies a whole collection of functionality is in place, all of which contributes to the editor being sufficiently robust and flexible to meet any challenge you can throw at it, whether it involves editing repetitive text or something else entirely.

      1. To turn the output of pasting Mark's example into a function you could do.

        function MyCommand()
        normal! 0ct(<c-r>=”P<esc>jjj.3l4xn
        endfunction</esc></c-r>

    1. For the record (no pun intended) when you record macro 'a' with qa…something…q you can see the codes if you paste record 'a'. thats…

      “ap

      double quote and then a letter chooses the named buffer, then p to paste after the cursor. by that same concept you can copy to a named buffer, let's say 'w'….

      “wy

      And then run it with @w

      1. That's a good tip. It's annoying to record a 20-character macro and get something wrong in the middle. This way, I could conceivably fix it without rerecording it.

        However, I don't think this is what Avdi is talking about.

          1. No, it's not. 🙂

            What you get with Guillermo's suggestion is something like

            0ct(<c-r>=”P<esc>jjj.3l4xn

            which is not VimScript and could not automatically be converted to VimScript.

            (I was trying to show Vim keycodes in angle brackets but was not very successful. You get the idea, though.)</esc></c-r>

  4. TextMate does #1. Not quite as you say; the macro gets saved as an xml file, and textmate discourages editing it, preferring that you re-record it… but there's nothing stopping you editing it by hand. Macros get saved into “your bundle”, which is a redistributable collection of the commands/snippets/macros/templates/whatevers that you've made yourself, and it's easy to split stuff out into a standalone bundle.

    #2 I'm not completely certain of. There are options not enabled by default for autosaving every time your window loses focus, and performing atomic saves… but I have no experience with catastrophic crashes, so I can't honestly say how well they've worked out.

    1. With options like that, it sounds like the TextMate developers are at least thinking about and taking data integrity seriously.

      Strange about recording macros – how do you go about taking a specific recorded macro and tweaking it into a more generally useful script?

      1. TextMate's general paradigm for more complicated scripts is that they should be written as shell-scripts (anything with a shebang) that accept input on stdin, with the script itself declaring whether that input should be the whole file, the selection, or nothing.

        This is sort of good and sort of bad; it gives a lot of flexibility in how you want to write a command, but it introduces a perceptible delay in some actions, because the only way to do things like move the cursor around from one of these scripts is to run another program.

  5. Switched from emacs to sublime. Sublime’s written in Python and you can get to the python interpreter. It does let you record macros and define your own key bindings. I liked emacs a lot, but it shows its text heritage and I didn’t like that after a while, despite being an old text head from the 1980’s.
    I still find myself switching to Vim or Emacs to do regexp replace though (talking about the 1 2 stuff). None of the ‘modern’ editors do that properly (or at all) and don’t seem to see how important it is. Been using that since the original Vi.
    Recently got an Android gig and have been using Eclipse a lot. After turning on some of the emacs features (^A ^E ^K ^Y) it’s ok. I like the way you can select lines, press a combo with the up/down arrows to copy and then move them somewhere else. I set sublime up to do this on the same keys too. For a strongly typed language Eclipse is really good, and handles the Java rat’s nest of adapters thing really well.
    Never got on with text mate – having to press alt (or is it shift) to turn on “replace in selection” – just no.

Leave a Reply

Your email address will not be published. Required fields are marked *