🖋Text Editing Fundamentals

We, developers, spend a large part of our days writing, editing, and reading code. During the lifetime we probably write millions of lines of code and edit about twice as much.

These large numbers are what makes text editing a good candidate for performance optimization! Increasing your text editing efficiency just a bit yields tremendous results in the long run.

Though, one of the most common arguments against optimizing the editing experience is that programmers’ primary activity is thinking, not writing. That is true, but I believe it misses the point.

Once you harmonize with your editor, text editing becomes an unconscious activity—the editor doesn’t get underfoot, and you edit code at the speed of thought! That streamlines thinking process and helps to maintain the “flow state”—an almost-mythical mental state of high focus and full absorption in what you do.

In this article, “text editor” refers to both text editors and full-blown IDEs. Every IDE includes a text editor as an integrated part, and all modern text editors have many IDE features, so the border is kind of blurry.

Editor is your tool

As carpenters use a variety of woodworking tools, developers use a variety of programming tools—text editor is likely the most important of them.

An experienced craftsman knows his tools well and uses them efficiently, without thinking. The tool becomes an extension of his hand. Likewise, the text editor should become an extension of your hand.

Note that a great tool won’t make you great craftsman automatically. It is also possible to create a masterpiece with primitive tools. Good ones merely make the process easier and faster.

Touch typing

Touch typing is a method of typing without looking at your keyboard.

If you don’t touch type yet, this is the skill that could give you an enormous upswing in efficiency. While this is not directly related to text editors, this is such an essential point that it’s worth mentioning here. Typing millions of lines is lots of work—typing them all with two fingers is well daunting.

There are two main benefits to touch typing:

1. Increased typing speed.¹

   A million lines is a lot of typing—if you type faster, you save time. If you upgrade from 40 to 60 WPM (which is still not much), you literally save months of punching keyboard.

2. No attention alternation between your keyboard and computer screen.

   You don’t need to look at your keyboard so that you can focus on the text you type and detect typos early. (It sucks to spend hours debugging to find out that you made a typo.)

I don’t want to derail this article any further, so here is a quick start for touch typing:

1. Use typing tutor. There are a lot of them out there—google “touch typing,” try a few, pick one you like.

2. Don’t try bashing keys for hours straight and stress yourself—be consistent instead. Exercise 10 to 20 minutes daily. Do this for at least a month or two.

3. There is no step 3.

Choose your weapon

There are many good editors. If you stick with the first one you find (or someone recommends you), you’ll probably miss a lot of better ones. Research available options, try them, learn them, pick one that aligns with you well, then use it for everything.

“Learn” is an important part. Many powerful editors require some upfront investment—if you don’t give them enough time (or at least read about them), you won’t discover their philosophy and unique offerings.

Good editors have super-power to them. Choose one with the super-power you love.

Important considerations

These are some high-level properties you most likely want your editor to have.

• Keyboard-driven

  Moving your hand from keyboard to mouse and back takes time and energy. It is not instantly noticeable on a single move, but if you do this exercise a thousand times in an hour, the effect adds up.

  Keyboard-driven editors make all functions accessible from the keyboard without the need for touching the mouse.

• Integrated

  The editor should be able to co-operate with the rest of the tools you use. It should create an integrated environment for development.

  You should be able to do all the work without leaving your editor. That includes (but not limited to) navigating through the code base, compiling, linting, testing, and running your application, working with your version-control system, executing shell commands.

• Configurable

  You should be able to configure every bit of your editor, including fonts, color theme, key bindings (mappings from key to feature), code style settings, you name it.

• Extensible

  Good editor grows with you. It should be able to accommodate new languages as you learn them.

  If you learn new programming languages regularly (and you should), picking up a new editor every time is not an option.

• Programmable

  The editor should be able to perform complex sequences of actions. That usually comes in the form of either macros or built-in scripting language (or both).

  It might be a good idea to choose an editor that can be configured with a language you’re comfortable with.

• Portable

  The editor should also be cross-platform to support you migrating between different operating systems. If your editor is exclusively available for a single platform, you might find yourself vendor-locked into your OS (which is a Bad Thing™).

One vs. multiple

Ideally, you should use a single editor for all your editing tasks. This way you won’t have to learn different editors and could focus on mastering the one. Using multiple editors also hinders your muscle memory as they likely provide different features and different key bindings.

I write this article in the same text editor I use to develop this website, manage my todo lists, and write some 10+ programming languages. Oh, and I read, write, and send emails from it, too.

Practically, this is not always possible or feasible as some environments are inherently inflexible and force you to use a specialized IDE. Configuring your editor to not suck in such an environment might require an absurd amount of time and effort.

If that is the case, give in and use that shitty IDE. Don’t make a blind cult of your editor.

If you need to fix an unobvious bug in a huge legacy Java application (I am sorry for you) and you never programmed Java before, it might be impractical to teach Java to your editor. In that case, install one of the shiny off-the-shelf Java IDEs and get the job done.

Don’t make a blind cult of your editor.

Recommendations

As you might get it by now, the choice of editor is a rather personal one. It depends heavily on you, everyday tasks, your background, and environment. I don’t want to bias you too much so I won’t recommend single editor—instead, here is a short list of editors I find all worth trying.

• Visual Studio Code. VSCode is an open-source text editor extensible in JavaScript. Available on Linux, macOS, and Windows.

  It is easy to start using and provides enough room for growth.

• Vim. The main feature of vi family is their unique modal editing philosophy. This philosophy is a cornerstone of Vim and is the source of both high productivity and the steepest learning curve.

  This powerful unorthodox editing model is what makes Vim worth checking out. Vim is also the most portable text editor in the list—it comes pre-installed in many operating systems, and all other editors in this list provide Vim emulation plugins.

• Emacs. Emacs is open-source and is the oldest source code editor in the list (but is still actively developed).

  Emacs is a paragon of extensibility. It is mostly written in Emacs Lisp and uses the same language for configuration and extension. This makes Emacs hackable to the core.

• IntelliJ IDEA or other JetBrains IDE. IntelliJ IDEA is a Java IDE, but it has plugins for many other languages as well. It has both open-source and proprietary versions.

  IDEA provides many powerful features and great out-of-the-box language integration.

Efficient use

Now that you chose an editor, it’s time to become more efficient using it. It’s going to be a lifelong process (as you can always optimize one more thing), but very simple at its core.

It only has three steps:

1. Detect inefficiency

   You should continuously go meta about your text editing. Pay attention to how you edit text, find an action you often repeat or spend a lot of time on.

2. Find a quicker way

   Any powerful editor provides a way to do your work fast. You just have to find it.

3. Make it a habit

   Train yourself to use the new behavior.

This simple but profound technique will help you top the performance. You just have to use it.

This section is an excerpt of Seven Habits of Effective Text Editing by Bram Moolenaar. It takes ~20 minutes to read the full (highly recommended).

Alternatively, check 1 hour 20 minutes talk (slides).

It is your editor

All good editors provide an extension mechanism via scripting language and plugins (if your editor doesn’t, seriously consider switching). That is an essential feature for a programmer as it opens the window to virtually endless customization.

If the editor does not provide a feature you need—you may implement it.

• If you find yourself performing a particular sequence of actions often, bind it to a single keystroke.

• If you type the same boilerplate code over and over again, extract it into a snippet.

• If you’re not satisfied with editor behavior—fix it!

You may change every aspect of your editor to the point it is inoperable by anyone else, but it is a perfect match for you—it becomes your editor.

If you use other people’s computers often, don’t go too wild so that you can still use their editors without too much pain.

Balance!

Sharpening your tools is addictive. It is easy to derail yourself into configuring the editor instead of doing actual work. (You’ve been warned.) Try to keep the balance.

I find it helpful to keep a list of all improvement I want for my editor.

So when I think of a cool feature to add, I jot it down instead of jumping into implementing it (and procrastinating the work). I review this list regularly and plan improvements. This process helps to filter off one-time desires.

Avoid holy wars

Text editors are a topic it is easy to get religious about. You might be tempted to prove everyone on this planet that your editor is the best and they are fools for not using it. When you meet another person, who thinks that their editor is the best, that produces a heated debate.

I would say that that’s a rather useless waste of time. First of all, nobody is really listening to you; they have the same objective—prove their editor is the best, not figuring out that they might be wrong. (Unfortunately, you do not listen to them either.)

Just remember that you can be effective with most of the editors—it’s mostly a function of how much you invest into it.

Footnotes: