It Doesn't Matter Which Text Editor You Use

Obviously, Neovim is the best text editor. But in 2023, it mostly doesn’t matter. The power of a text editor is in its plugins, and now that we have Language Server Protocol (LSP), you should be able to achieve the same functionality everywhere.

The old way of doing plugins

Suppose you want to write a plugin that indents Rust code in Emacs. Well, you’ll probably need to learn Elisp, dialect of Lisp that Emacs is written in. It will take some time to learn the language, implement parsing, and figure out how to programmatically manipulate text inside Emacs. But it’s doable.

Suppose that after you’ve written the plugin, an intellectual friend of yours asks if he could use it in Vim. Well, not right away. Although the parsing part can be reused, you need to understand how to programmatically manipulate text in Vim. Even though the functionality of the plugin is the same (inserting or removing spaces at the beginnings of lines for various indentation levels), this is probably done differently in Vim and Emacs. But, again, it’s doable.

If you have n text editors, you will need to write n versions of the same plugin. And if you have m different plugins (say, for indenting code in m different languages1), you will need to write m × n variations of plugins to cover each language and each text editor.

Complete bipartite graph with m vertices (programming languages) on the left and n vertices (text editors) on the right. There are m × n edges between the vertices, denoting all plugin implementations.

The LSP way

The key thing to recognize here is that the functionality of a given plugin is the same across all text editors. So maybe there is no need to repeat the same work over and over again?

LSP is an attempt to standardize all the things that a text editor might be able to do: insert text, find references, rename variables, display errors, etc. Any editor that supports LSP can be interacted with using the same commands instead of editor-specific languages or configuration files. Then, a given plugin only needs to be implemented once by using features provided by LSP; it will work in any text editor that supports LSP.

If you have n text editors, you will only need to add the support for LSP in each of them once. Similarly, as mentioned before, each of the m plugins only needs to be implemented once by following LSP specification. Although the things being implemented are different, we can essentially say that we reduced the complexity of the problem from m × n to m + n.

A graph in which m vertices (programming languages) are connected to a vertex representing LSP and n vertices (text editors) are connected to the same vertex. Inside the LSP block, some features are mentioned: inserting text, finding references, renaming variables, and displaying errors.

So what?

Unlike most standards (see below), LSP seems to have succeeded.

XKCD comic:

These days, most of the serious text editors support LSP—indeed, it’s become almost a requirement to be taken seriously. That is not to say that all text editors are now equal—they all do things differently. It’s just that there is no longer any point to argue over the technical capabilities of each. With the proliferation of LSP implementations of plugins, it’s rare to be able to achieve something in one text editor but not in some other.

Finally, if you are crazy enough to want to write a new text editor, maybe it’s not such a bad idea—if you add support for LSP, you’ll now automatically have access to an amazing ecosystem of plugins!

  1. Yes, I know, it’s a bit different in Python… ↩︎