Text Editors

As software engineers, and programmers, we mostly work with text, so obviously we’re all using some sort of a text-related program. Editing and navigating text is a huge part of our daily job, so a good text editor is like a good set of tools for blacksmiths. A good blacksmith may still do their work with inappropriate gear, but will be more productive, and the end result will be in much better shape if good tools are at hand.

The same goes for programmers - a good text editor enhances our productivity and makes navigating (and thus understanding) the project we’re working with a bit easier. Well, a good programmer can write everything in the simplest of editors, or even on paper, but I think no one will argue that a good text editor will boost our work tremendously. Don’t take this post too seriously though, as I think text editor is kinda personal thing, and for most users, key features will differ, so I’m not expecting anyone to 100% agree with me. As always.

There are several classes of text editing tools, which are different in many ways, and are used in different situations, like pagers, IDEs, hex browsers, stream editors, and so on, so in this topic, I will only touch a small subset of whole text editor world - advanced text editors. Such editors are not as simple as plain text editors like MS Notepad, and not as complex as IDEs. I would like to begin this with a look at default editors in GNU/Linux, which usually are provided with a desktop environment. These kinds of editors are worth to be mentioned here because I think that it is a good thing to have, and sometimes those are in fact usable.

Gedit, Kate, and other default editors

Default editors are a kinda weird thing, though. I mean, it is great to have a default editor in the system, because casual users sometimes, actually, edit files, but both Gedit and Kate are trying to be hackable developer-friendly editors. While this is not an issue, I don’t think that this is necessary. Hear me out though.

Let’s look at Gedit first. This is how it looks by default on the GNOME Shell desktop:

Not much to see, looks like a very basic editor. And I think it is one hundred percent fine because if you need to quickly tweak some configuration files it is more than enough. However, it’s not all that Gedit can do. There’s a plugin section in the settings, that features some preinstalled plugins, and users can search for extra plugins online or in repositories. So if we tweak some plugins and enable some settings, we can get this result:

This setup may be a bit more useful for you if you decide to use Gedit for development in some language, that Gedit supports. With file browser you have quick access to related files in the project, mini-map is kinda popular because of Sublime Text I think, and line numbers are, well, line numbers. But I don’t think that all of this is really necessary for Gedit.

The thing is, I don’t think that anybody expects an operating system to have a built-in, graphical, advanced, extensible, development-ready text editor. Maybe it’s just me because for too many years Microsoft offered very basic Notepad with Windows OS, and WordPad, which is aimed towards writing documents, so I apply this concept to GNU/Linux as well, shame on me. Sure, if you’re a system administrator and you’re setting up a new machine, or logging to remote servers you expect a more or less advanced editor to be installed, which usually is the case for most Linux distributions to have something like Nano or Vim. But when speaking about graphical environments I think that such a very basic editor as Notepad is more than enough. It can open files, edit those, and save them. So instead of adding these plugins, developers could focus on more critical parts of their desktop environment. I also doubt that Gedit or GNOME developers use Gedit to develop their respective projects, given that there’s also GNOME Builder thing. Maybe I’m wrong though.

Pretty much the same goes for Kate¹, Mousepad, Pluma and others. But for professional use, these editors are still far behind everything else. And moreover, both GNOME and KDE projects have their own dedicated IDEs - GNOME Builder, and KDevelop respectively. I think this indicates that both Kate and Gedit should not be as advanced as they are, because there’s a more advanced tool in the very same project already, aimed at programming. Well, KDevelop uses some of Kate’s code for their editor, and GNOME Builder maybe does this as well, so Kate and Gedit can benefit by getting extra features from those projects, but maybe the focus should be shifted to KDevelop and GNOME Builder, and both Kate and Gedit should be left as a basic system editor.

Don’t get me wrong, I think that this is good to have open source editors, that are both hackable, and provide a good set of tools, and I know that many really use Kate for development, but I don’t know any advantage that Kate has over any other editor. Also, let’s look at the popularity chart:

This is not the most accurate data, I’ve taken it from Google Trends, and put Mousepad, Kate, and Gedit into a single category because the point of interest of each of those was less than 1%, compared to any of the competitors. In comparison, Sublime Text, Atom, Vim, and even Emacs are much higher in this chart. Why?

I think one reason is since these editors are already preinstalled no one really searches for those, thus the point of interest is very low. The other reason is that, perhaps, users first try a preinstalled solution, and after that search for a more advanced tool, that supports their workflow or project-related tooling. Again, don’t get me wrong, Kate and Gedit are both very capable text editors, but get fully outmatched by any of the other competitors listed in the chart.

Another problem is the plugin ecosystem. Kate features plugins in C++, and I think that this is the worst decision I’ve seen. This may be good for speed and integration because Kate itself is written in C++, but I think it is not good for the ecosystem. Considering that Kate has a small user base, and an even smaller part of that users care to write plugins, and an even smaller part of these plugin writers are capable of developing in C++ because C++ is a very complex language, it has to be a miracle for a plugin to appear. Although Kate developers can create such plugins, and I think that is the primary reason why C++ is supported for plugin development.

However, both Gedit and Kate can use plugins written in Python, which is a much better option, though implementation language is not the most important thing here, because plugin API also matters. I don’t know how good or bad Gedit and Kate python APIs are, so I will not make opinions on those. But given that Gedit doesn’t have as many plugins as other editors listed in this post do, I think it’s not the best one. Maybe.

But plugins are not the only thing that will lead text editors to success. Most editors that will be listed afterward had a killer feature that was the reason why programmers cared about trying these editors in the first place. I think both Kate, Gedit, Mousepad, and other built-in editor features is that those are preinstalled on the system. I also don’t think that this is the feature that will make most programmers choose these editors.

So what exactly makes other editors stand out? Let’s walk through each of those ones by one.

Sublime Text

Originally, Sublime Text was meant to provide an experience close to TextMate (which I will not touch here because I don’t have a Mac to check it), but for the Microsoft Windows platform, and later was ported to GNU/Linux and Mac OS. It was a massive hit when it came out in 2008 and still is a very popular editor. What makes it stand out today is its speed - it’s blazingly fast! I’ve tested it on a relatively big C project (8k source files, 8k headers) mounted via sshfs and it was the fastest editor in terms of opening files with its fuzzy search. So what makes it a good choice aside from its speed?

• Fuzzy search.

  Sublime has this neat feature when you can open a special prompt and type an incomplete string, and it will find every possible match. For example, if you’re looking for file called this_important_file.txt you can press Ctrl p and input timpe, and Sublime text will find this file with this kind of match: this_impportant_file.txt or something like that. It will also list all other possible matches and rank those via some algorithm.

• Language support.

  Sublime text has support for TextMate grammar files, as well as for its own grammar system. This makes it support all TextMate-supported languages, plus its own set of other languages, which sometimes overlap with TextMate’s grammar, but provide more smart syntax highlighting.

• Plugins.

  There are many plugins for anything you can imagine. And those are written in Python, which at the time was a very viable option.

• Cross-platform.

  Because it works the same on all major systems it is a great choice if you often switch those, either because you have Mac at home and Linux at work, or MS Windows, you will always find Sublime Text for these platforms.

• Multiple cursors.

  I’m not sure where this feature first appeared, but if I’m not mistaken, Sublime Text was the editor which really popularized this feature, and it became sort of a standard thing for most post-Sublime editors. Essentially multiple cursors allow you to place several cursors in your file and edit text simultaneously. You can select the text, cut, paste, delete, type, and so on.

• Go to anything.

  Sublime Text has parsers for many languages and allows you to jump between definitions in the project.

Interestingly enough none of these features are anything special for today’s editors. Many are cross-platform, and most of the new editors have multiple cursors, fuzzy search, and go-to. Plugins in editors were before Sublime Text. Yes, Sublime Text was very popular because of these features, but today I think only speed is what stands it apart from others. I’ve never used Sublime Text for work because it is not free, and not open source, so I can’t say much beyond that list. I try to avoid as much proprietary software as I can for the last 10 years. And especially when there are better options available in the land of text editors.

Let’s talk about relatively new ones that are quite popular today, and shifted Sublime text from its absolute dominance to third place.

Atom and Visual Studio Code

Oh boy, this is hot! Really hot! I mean why fan in my laptop spins like I’m playing a video game? Oh, it’s because I’ve opened these two editors side by side.

Just kidding. It’s fine, but this performance-related pun is still a thing, unfortunately, because each of those editors eats more memory and CPU cycles than Sublime Text, and overall performance is not that good. Why? Because these editors are not exactly editors. These two are web browsers that were turned into text editors. A bit of story behind the technology:

Atom was created by GitHub, and based on Electron technology, which also was developed by GitHub, which is essentially a slimmed-down Chromium browser. Electron allows developers to create desktop applications using web technologies. I actually think that this is one feasible future because possibilities with this approach are mostly endless. I mean, today browsers can view PDFs, run interactive scripts, play videos, run 3D games with hardware acceleration, and so on. Because everything I’ve listed is related to displaying things, let’s call this rich rendering. Currently, the browser is an ultimate window that can do mostly anything you want it to. And if such technology powers a text editor, I think we only win.

So what essentially rich rendering provides, is the ability to create any kind of interface, because you have full access to the DOM, styles, and markup, and you also have browser rendering capabilities to back all of this. For example, we can create a popup window that is pinned to a concrete line, and when you scroll view, this popup window moves with that line. This popup can have its own scrolling capabilities, and other interactive features, such as displaying graphics, because it is essentially just an <div> tag with some display properties. For example, we can really see that in the developer console inside Atom:

But unfortunately, as always, there’s a cost. Web interfaces are really flexible, but we sacrifice performance for this, because although the web is kinda speedy, it’s not as fast, as it could be with some native code for interface. I doubt that Atom or VS Code would ever be as fast as Sublime Text, though Atom seems to realize that in order to speed things up it needs proper technology, so some parts (e.g. Tree Sitter - incremental parser framework, the search can use ripgrep tool) are now written in native languages. There was a project that aimed to rewrite the core of the editor in Rust but unfortunately was canceled.

And even though both Atom and VS Code are written in JavaScript on the Electron platform, these editors are different. Not only in implementation, since VS Code is written in Typescript, and Atom in plain JavaScript, but the main difference is in the approach to extending and configuring the editor. Both Atom and VS Code feature plugins are written in JavaScript. Both Atom and VS Code can install plugins from respective stores. The same goes for Sublime Text.

But Atom claims that it is “A hackable text editor for the 21st Century” and is hackable to the core. Which is quite true. Visual Studio Code and Sublime Text use plugins in a more traditional way. E.g. in Atom packages can change how the editor works, while Sublime Text and VS Code plugins mostly add features on top of how the editor works. Let’s look at this screenshot of Atom:

See this file tree on the left? This bottom panel with file information? Tabs? These all are separate plugins or packages as those are called in Atom. And you can turn those off just as packages that you’ve installed. And you also can replace those packages with something entirely different, if you want. Atom features really good defaults and configurations but is also eager for you to make it your own. This can be said for VS Code as well, but I’ve found some limitations compared to Atom while testing this.

What differs Atom from VS Code² is that users also can tweak editor with CoffeeScript, which makes Atom truly hackable to the /core/because Atom itself is written in JavaScript. Although not really to the core, but rather down to the API of the editor, this is still huge. And that is another feature of Atom that I truly like. Just watch this talk by Jason Gilman about REPL for Clojure, which adds some amazing capabilities to the editor, and deeply integrates with the running instance of the REPL. It’s amazing. Not that you can’t make the same thing for Sublime Text, or VS Code, but I think it is much easier in Atom because Atom embraces the fact that anyone can hack upon it.

Visual Studio Code on the other hand is not that hackable. Well, it is quite hackable, VS Code features a good API for plugins, and many internal interface elements are developed using this API. You can change it, but Microsoft still has a view on how things should work and what should be in the editor. This also has some benefits. Both Atom and VS Code feature the box setup, though VS Code tries to be a more complete IDE-like solution focused on development, while Atom is focused on development and extensibility.

But the killer feature of Atom and VS Code is rich rendering that I’ve already mentioned before. Because the capabilities of the rendering toolkit are basically the same as in a web browser, we can add any kind of graphical interface to the editor. It can be an advanced color picker, if you work with CSS styles, a PDF viewer, if you’re working on documentation, a video player, if you’re testing out your site that has video, toggle switches, or sliders for real-time adjustments of values - anything is possible. This allows us to create the best interface we may want or need to be more productive, without relying much on the graphical toolkit we’re using, because the web is now our graphical toolkit. This is good for creating interfaces that suit your developing needs. I highly suggest you watch the talk by Bret Victor, called Inventing on Principle. It highlights the need for exploration of the domain we’re working in, which is computers, and in the case of Atom and VS Code web stack.

There is another kind of text editor, which is more texty. Those embrace text as their main focus and data format, both have text-based interfaces, and both are extremely hackable. I’m talking about two eternal rivals - Vim and Emacs, as well as about most other TUI-based editors. Let’s look at those in detail.

Vim

Behold! Vim, the king of text editors.

Vim has a very long history as a text editor. The predecessor, Vi, had many features that were really useful at the time, such as modes, but were proprietary. It was open-sourced later, but there also were several clones of Vi editor, and Vim is only one of those. Vim stands for Vi Improved and adds a lot of features on top of the Vi formula. So what Vim is like? Let’s have a look:

Not like there is much here to see. Just like in the case of Gedit or Kate. However, like other editors Vim supports plugins. These plugins can change Vim quite heavily. As in Atom, you can add tabs via a plugin, change status line appearance, add file explorer, tag browser, and so forth. Furthermore, like Atom, we have a way to create custom interfaces using plain text. In Atom, we can hack upon the DOM and CSS, and in Vim we can hack upon lines of text, and highlighting. For example, the file tree here is fully interactive but is essentially text. Here’s my old Vim setup:

But the visual look is not the most important thing, especially for Vim. I’m no longer a Vim user myself, but given the popularity chart I see that many developers use it. So what are the key benefits of Vim? I think these are quite heavy arguments:

• Vim is fast. Really fast.

  Sometimes it is slower than Sublime text, on really large files, but still much faster than other editors I’ve talked about.

• Vim is quite lightweight.

  Although it has a somewhat large codebase, and there are projects to eliminate some of the issues related to it, like NeoVim, Vim is still quite lightweight. By default, it provides very basic features, yet those features have deep semantics. And it starts fast too.

• Vim is extensible.

  Vim can be extended with vimscript and python, NeoVim also expanded the ability to extend Vim with many more different languages, like Lua or JavaScript.

• Vim is not a generic text editor, rather it is an editing-language environment.

  What this means is that in Vim you don’t have shortcuts, like in other editors. Instead, you have the language, with verbs and objects. So to delete to the word end you press dw, where d is for delete, and w is a motion you apply your command to, in this case a word forward. If you want to delete a current word, you can do diw which would stand for delete inside word, and if you want to delete a word and whitespace after it you use daw, or delete around word. This language has quite a lot of depth, and some commands can be combined in different ways.

Because of that Vim is mainly a keyboard-driven editor. And this is a huge thing. If you never have to touch your mouse, and you never have to move your hands from your keyboard you are already much more productive than any other developer. Unless you do visual programming.

I think that Vim’s killer feature is its editing model. It is verb-object, you decide what you want to do, and what you want to apply that modification to. And I think this is where Vim’s strength lies. You can combine commands into complex sentences that deal with text for you, and you can store those in macros, to invoke later, or repeat the last modification with . key. This is a powerful concept, and Vim executes it quite efficiently, and editing language definitively stood the test of time. Plugins also can extend this language with additional verbs and objects. However, I’ve mentioned that I’m no longer using Vim because I’ve found a more interesting approach to editing text while still using a Vim-like model.

Kakoune

This editor definitely is something. The main difference from Vim is that Kakoune uses an object-verb system - you select first, then edit, so Vim’s dw becomes wd in Kakoune. And the main feature of the Kakoune editing model is multiple selections. Not multiple cursors, like in Sublime Text, or VS Code and Atom, but selections. To get a better understanding, you can think of selection in Kakoune as Visual mode in Vim, which essentially allows you to select any text and treat it as an object for your next move. Kakoune extends this idea by allowing you to have more than one selection at the same time. And furthermore, Kakoune doesn’t have a cursor at all. It is always a selection, and most of the time it is simply a single char selection.

By default, it doesn’t look much different from Vim. However, we can tweak its appearance with some plugins, to make it look somewhat more like an interactive development environment:

Just like in Vim, we can create a custom interface out of text and syntax highlighting rules. But again, what’s important - how it looks, or how it feels? Kakoune feels refreshing and is a modern take on Vim. Unlike Vim, Kakoune is much simpler - it does not include window management, it does not have its own scripting language, and for me, this was a big no-no when I first saw Kakoune. However trust me, the lack of language is not a problem for Kakoune, and it does not need window managing capabilities at all. And Kakoune is also pretty fast, and my tests showed that it is generally much faster than Vim on big files. Especially highlighting. Although Kakoune uses more memory to cache everything it highlights, so there’s always a trade-off.

So what are the strong points of Kakoune and why you may want to use it? For me, it was first-class support for multiple selections and structural regular expressions. In Kakoune it is possible to select a big chunk of text, then hit s key, and input a regular expression, that will be used to select everything that matches in that original selection. Then you can repeat this process and get selections of that sub selections. E.g. if we wanted to select every variable that has _count, but without that _count part we would do this:

Of course, we could do it a much simpler way by selecting paren|bracket|curly regular expression. This example is made up, but with more complex regular expressions it makes this feature really handy. I’ve written some plugins for Kakoune, one of which was tagbar.kak, which provides a side panel with tags for the current buffer, and it uses universal-ctags. In the source code of that plugin, there is a big block of code that was generated by using multiple selections over the complete list of ctags kinds for all languages all at once. So this is something like real-time interactive sed.

Speaking of plugins. Kakoune features the weirdest, yet really great way to extend the editor. All editors that we’ve seen so far used some kind of language and an API to write plugins. Some editors use their platform language, like JS in Atom or VS Code, and Kate with C++ plugins, other use some other languages, like Python. Vim has its own vimscript language, and an API to work with Python.

I’ve already mentioned that Kakoune has no built-in scripting language. Well, kinda. In fact, it has a very basic scripting language, called kakscript, but it has no control flow except try and catch, and is only used to create basic commands. However, you can go far with it, because it allows you to execute Kakoune keys, and all other Kakoune commands. For example, most indentation handling is done by searching for the previous line, copying its indent level, adding a needed amount of indentation to that level, and applying it to the currently indenting line. Because Kakoune features very fast regular expression language and is quite robust on its own this is one feasible approach to writing plugins.

The other one is shell expansions. Kakoune supports various strings with syntax that uses percent and pair of delimiters, for example, %(str), %{another str}, and %|yet another|. You can use other delimiters too. This is useful for various expansions, like %opt{option_name} or %val{value_name} are also strings, but those will expand to the respective values stored in these variables. This way you can write a string like "current line is: %val{cursor_line}", and it will expand to the current line number. Kakoune also has this special kind of expansion: %sh{…}, that expands to shell call. So everything that is inside curly braces will be your average shell script. Kakoune strongly suggests using POSIX shell scripting environments, so it could work on all POSIX-compliant systems. And with shell, you can use any language you want!

Kakoune exposes its state via shell variables that begin with kak_ prefix. Internal options are available with just this prefix, user options with kak_opt_ prefix, registers with kak_reg_ and so on. This way you can see the current selection in a shell expansion as $kak_selection. And if your plugin defines some option, you can expose it to the shell as well.

This allows users to build any kind of plugin without much API. We only see the current state of Kakoune and use it to produce some results. Of course, plugins can interact with Kakoune, and it is done through pipes. You can pipe arbitrary Kakoune commands to a running session like this:

:eval %sh{ echo "execute-keys -client $kak_client gg" | kak -p $kak_session}

This will jump to the beginning of the buffer. So if you know your session, which is PID of Kakoune, you can interact with Kakoune from the outside world. This is a quite flexible system, and it adheres to the design of POSIX-compliant tools that can also work with Kakoune, not just Kakoune plugins that are usable only in Kakoune itself. As a consequence Kakoune can be integrated with a huge amount of console tools starting from file managers like nnn or ranger, expanding to fuzzy search engines, search tools, git clients, and so on, and also window managers.

So when I said that Kakoune doesn’t need its own window managing facilities, I meant that you can integrate it into any other window manager, like i3wm or Bspwm, terminal multiplexers, such as Tmux or GNU Screen, or terminal built-in splits like in iTerm2 or Kitty.

The downside of it is that you’re using a human interface as a programming interface. You see, the shell is meant to be used by humans, and writing programs that manipulate the shell is hard. Such programs have to parse output, generate valid input in response, and so on. Some programs, like git, provide porcelain mode, that is parser friendly and versioned, so your application will continue to work if Git changes and you’ve written code correctly. But not all applications are like this, and some of the systems ones work differently on different systems. For example, I’ve written that filetree plugin that I’ve shown on the second Kakoune screenshot, and I had to parse the output of ls program. But ls as in GNU don’t work as BSD’s ls. So I had to write cross-platform calls to ls which limits me. I’ve also used Perl to parse this thing, and a lot of other shell tools, that are also not that portable. The last bit is that all shells are different, and bash differs tremendously from ksh. This is quite a downside for plugin maintainers.

If what I’ve said about Kakoune concerns you and you think that it is not for you, but you want to try out multiple selection workflow, then you should check Vis editor. It is quite similar to Kakoune and uses multiple selections as its central way of interaction with the text. It is also quite minimal, and fast. However, I’ve never used it myself, though as far as I know, it may be more appealing to Vim users, because it doesn’t flip the verb-object way of interaction like Kakoune. It also uses Lua for scripting, which I think is a good approach too, because Lua is great for embedding.

But there’s yet another very special editor I want to discuss. I’m using it quite heavily today, and it is my main tool of work for several months already. And this editor is Emacs.

Emacs

Behold! Emacs, the true king of text editors.

What we immediately can spot is that Emacs can display images, different font sizes and fonts, in the same buffer, it has some graphical interface and… And that’s it. Don’t judge by the look though, this beast is powerful as hell. These features already make Emacs stand out, compared to Vim or Kakoune, but are not yet sufficient to compete with Atom or VS Code, which have rich rendering systems, thanks to web technologies. Emacs can’t compete with Sublime Text in terms of speed as well, but there are reasons for that. Although we take these graphical features for granted today, Emacs is a really old editor, it was released about 44 years ago, and these features were added way before Sublime Text was even in development.

But these are just cosmetic features to many of us, what’s so special about Emacs besides that? Well, first of all, Emacs is not strictly a text editor, much like Atom. Emacs is built on top of a virtual machine, which has an interpreter and byte-compiler of Emacs Lisp language, that was designed specifically for Emacs, and it is one of the oldest Lisp dialects that are still in use. This VM is written in C, and the rest of Emacs is written in Emacs Lisp. Although some core primitives for Emacs are written in C for speed concerns, we can still use those from Emacs Lisp or rewrite those in Emacs lisp if we really want.

So what this means? Emacs is more like an application platform, rather than a text editor. It has a text editor built in but offers much more than that. For example, things like Magit are possible and quite popular. Emacs has games, mail clients, chat clients, music players, and this list can go on. There’s a famous quote:

Emacs is a great operating system, lacking only a decent editor.

This is, in fact, kinda true. You see, by default, the Emacs experience is not really user-friendly. Given that it was developed using quite uncommon keyboard, all Ctrl and Alt shortcuts may be uncomfortable to use, and in general all keybindings seem quite strange and random. Famous example is directional keys Ctrl b is backward, Ctrl f is forward, Ctrl n is next, Ctrl p is previous. Although these keys have semantic meaning, many others do not. And heavy use of the control key is a pain point for many users. I personally remapped Caps Lock to be my Ctrl way before I started using Emacs (thanks to Vim), so this is not a big problem for me. But you can notice that on that keyboard the Meta (Alt) and Ctrl keys are swapped, compared to modern keyboards. We have Alt where Ctrl was, and that is partial reason why Emacs is so uncomfortable. But many keyboard-driven environments have keybinding-related problems, so let’s discuss more interesting topics instead. And this topic is Emacs Lisp.

Being a Lisp machine, Emacs has real language as its scripting language. Emacs Lisp may not be the best Lisp, but it is fine. It has some quirks but for the most part, it is good. But because this is also an implementation language for Emacs itself we can deeply integrate new features and change existing Emacs features by using it.

For example, imagine that you don’t like how your Ctrl w key works in Emacs. By default it kills region, or, translated to English, it cuts the selection. However Emacs often has an invisible region that is not active, but its beginning and end positions are defined. So if you accidentally press Ctrl w it will kill that region resulting in frustration and undoing. That often bit me, as I wrote a lot of text in one go, pressed Ctrl w thus killing all to the beginning of the file. What if we wanted to make this key work like it works in the shell, and still keep the default behavior if we have a visible region active? We can write our own function:

(defun aorst/kill-region-or-word (arg)
  (interactive "*p")
  (if (and transient-mark-mode
           mark-active)
      (kill-region (region-beginning) (region-end))
    (backward-kill-word arg)))

Now we can bind this function to Ctrl w and delete words before the cursor with a known shortcut, and cut regions when we want. This is a quite simple case, and you can do this in most editors that support custom keybindings and have a way to define a function. And in Emacs, every key is bound to some function, and such function can actually do anything. Another example is if we want to add a custom action to an existing function without redefining it. Emacs Lisp has an interesting way of doing this by using advice. It is something like a run time patching, that essentially says before or after doing that thing do my thing. For example, I don’t like that the external package doesn’t respect my custom function. I can advise it to check if I’m calling my function or not:

(define-advice lsp-ui-doc--make-request (:around (foo))
  (unless (eq this-command 'aorst/escape)
    (funcall foo)))

So whenever lsp-ui-doc--make-request function is called, we first check if this-command was not aorst/escape, and if it wasn’t we actually call lsp-ui-doc--make-request. This is a really powerful feature, which makes it easy to patch foreign functions in a way that you don’t have to patch them again until their signature changes. Or you can simply redefine function entirely with your own implementation.

The depth of customization you can apply to Emacs is probably endless. I’ve turned my Emacs into a visual clone of Atom editor because I like how Atom looks. See side-by-side comparison:

It’s not 100% clone, though I really like how it turned out, it is also important how it feels. And it feels great. I’m using many different packages that extend Emacs with various features like multiple cursors, custom keyboard-driven menus, linters, and so on. And the other thing is that Emacs is the only editor in which I’ve never actually seen serious problems with packages. In Vim, VS Code, and Atom, I’ve encountered problems with quite popular plugins, that prevented me from doing my work by either not working at all or having some bugs that made usage impossible. Never happened in Emacs. Of course, sometimes packages break, but it gets fixed really fast, unlike in those editors.

Which one is the best?

Perhaps, I was asking this question myself too many times. I think these editors are particularly interesting:

• Gedit, Kate, Mousepad
• Sublime Text
• Atom
• VS Code
• Vim
• Kakoune
• Emacs

If I were to rank those, it would be hard, so I would first split those into several categories and rank each. I think that there is no best editor, because best is a relative term, and it will vary between different people quite a lot. But we still can compare these editors and see which one is the best at what it provides.

First two categories would be out-of-the-box-ish editors, and customizable-ish editors. So for the OOTB editors, my ranking would be:

1. VS Code, Atom 🥇
2. Sublime Text 🥈
3. Kate 🥉
4. Gedit, Mousepad

This is a bit cheap to put Atom and VS Code at the same place, but I think that both are great. However I think that VS Code absolutely nails default configuration, and while Atom can be further customized to make it on par with VS Code, Atom still lacks some important things, like an integrated terminal.

Next go Sublime Text, because it is on par in terms of features with the first two, much faster, but I don’t personally care for the speed much, and abilities for further customization are what matters for me. Given that Sublime Text is focused on the OOTB features and speed, and you can extend it with plugins, you do not have the rich rendering and thus customization possibilities are more limited. And its default setup still lacks behind VS Code’s. Although it seems great for what it provides.

The rest are default editors, and I put Kate a little bit higher in the list because I see more potential in it compared to Gedit or Mousepad and others. Kate gets popular features, like language server protocol faster, so I think it deserves to be higher.

Now, I know, I did not include Kakoune, Emacs, and Vim in the previous chart, because those all are not OOTB enough, but their main focus is also different. So the second group is editors that are (kinda) focused on customization, and I would rank those this way:

1. Emacs 🥇
2. Kakoune 🥈
3. Vim 🥉

So why did I put Emacs to the first place? Because like Atom it features the deepest customization possibilities, even deeper than in Atom. And although the out-of-the-box state of Emacs is miserable this is not its key feature. If you really want OOTB Emacs configuration, there’s plenty to choose from and more.

Kakoune got second place, because its customization model is less direct, and encourages the use of POSIX tools, but you still can use any language through shell calls. Even Emacs Lisp is theoretically possible with Emacs batch mode, but why would you do that? This lifts the limitation of a particular language, and if you’re living in an isolated world you can even use a different shell for expansions, thus creating more advanced plugins in shell script alone. Although it is not recommended.

The last is Vim, and I do not like vimscript. I’ve written some plugins in it in the past, and maintenance of vimscript between Vim versions is kinda hard, and the language itself is quite chaotic. You can use other languages, but I’m not into it if the editor provides its own language. Kakoune provides a way to call shell, and Emacs has a pretty decent Lisp dialect, so those are better than Vim in my opinion. Yes, Vim features lots of plugins and customization options, which are more mature than Kakoune’s, but Kakoune is young so I think it is a time property.

The other possible way to rank editors is feature complete. This is tricky but I’ll try my best here:

1. VS Code 🥇
2. Emacs, Vim 🥈
3. Sublime Text 🥉
4. Atom
5. Kakoune
6. Kate
7. Gedit, Mousepad

Before you get mad (if you’re not already) let me explain why I think this is an acceptable ranking.

VS Code is on the first place because it gets a lot of plugins each week, and ships a decent amount out of the box, so most developers can use it without any configuration or with a really minimal one. This is important because an editor is a tool that should make us more productive. Also, I’ve found a syntax highlighter for quite rare language that was developed for in-company use only for VS Code, so it earns personal bonus point here.

Emacs and Vim share second place, but for slightly different reasons. Emacs has a metric ton of packages shipped by default, however, those are not really used or configured for a good out-of-the-box experience. It also has an insane amount of packages available online, and you can find practically anything for Emacs. Hell, you can order salads from Emacs!

Vim has fewer plugins built in, but it has mostly only necessary ones. Those are not enabled by default either, but at least you can browse through the manual and get an idea of what’s shipped. It has many plugins available online too, however, I found that they either have fewer features compared to Emacs ones or in general are less interesting. However, Vim keeps up by being a bit better as an editor. Although you have to learn modes, in Emacs you have to learn a lot of randomish keybindings.

Sublime text is very feature-complete, but I’ve seen some complaints by colleagues who use it about some missing features that are present in Vim.

Next goes Atom. It has good features in default shipping, however, I’ve found that a lot of popular packages are broken in either way and usually functionality is not as good as in VS Code or especially in Emacs. However it has interesting packages still, like Proto REPL³ or Activate Power Mode.

Kakoune is an interesting one. It is quite minimal and doesn’t have many plugins as of today, but the editor itself is quite young, so I have big hopes for it. Currently, existing plugins make it very usable, and more is yet to come.

Kate has more features out of the box compared to other default editors¹, so it is higher in the list. But overall it is still comparable with Gedit and Mousepad.

For the final ranking, I think I should use advisable-ish-thingy rating… In other words what editors are best to recommend for others.

1. VS Code 🥇
2. Sublime Text 🥈
3. Atom 🥉
4. Vim
5. Kakoune
6. Emacs
7. Kate, Gedit, Mousepad

Keep it cool, OK? I think VS Code as of today is your best choice if you need a tool and you need it right now. Before VS Code it was Sublime Text, but currently former is much more popular than the latter. If VS Code and Sublime are not for you, then I would suggest Atom, because it is quite close to those, but has some problems with packages. Next would go Vim, and only because it is the second most popular editor right now. After Vim is Kakoune, because, in my opinion, it is better than Vim, but a lot more bare-bones so you would need to tinker with it a bit more. Then Emacs, and I would not recommend Emacs to anyone just because it is a thing you have to come to by yourself. And the last thing I would recommend are default editors, because, well, you know if you can afford better tools why would you lock yourself to those that are at hand?

And for the final-final ranking, my personal top of editors is based on my own bias and opinion on each:

1. Emacs 🥇
2. Kakoune 🥈
3. Atom 🥉
4. VS Code
5. Vim
6. Sublime text
7. Kate
8. Gedit, Mousepad

Yes, I think Emacs is the best that happened to me so far, the best editor and application platform for text-related workflow. Kakoune is also an amazing editor, and though I mainly use Emacs, I still use Kakoune for multiple selection goodness when Emacs is not capable to do what I want.

Atom is just like Emacs, with really powerful customization abilities, and a good application platform, because it is not as restrictive as VS Code. But VS Code also is a decent editor.

Vim and Sublime Text are great, but I grew up from Vim, and Sublime is proprietary so is a no-go for me.

For the default editors, I think Kate is the most promising one, and I still occasionally use Gedit because it is often available on work machines we have at the office, to which I sometimes have direct access. Mousepad is the least interesting for me.

This concludes my kinda random thoughts on text editing tools. I hope this was at least an interesting read, and that you’ve found something new for you or maybe tried some editors you had not before. Although I must say that it turned out to be way longer than I expected.

Thanks for reading.