Text Editors – Andrey Orst

Text Editors – Andrey Orst 

As software engineers, programmers, we mostly work with text, so obviously we’re all using some sort of a text related program. Editing and navigating text is huge part of our daily job, so good text editor is like a good set of tools for blacksmith. A good blacksmith may still do theirs 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, good programmer can write everything in the simplest of editors, or even on paper, but I think no one will argue that 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.

xkcd: Real Programmers

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 the look at default editors in GNU/Linux, that usually are provided with desktop environment. This kind 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 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:

Figure 1: Gedit text editor

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 what Gedit can do. There’s 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:

Figure 2: Gedit with some tweaks

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, that I don’t think that anybody expect operating system to have 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, that is aimed towards writing documents, so I apply this concept to GNU/Linux as well, shame on me. Sure, if you’re system administrator and you’re setting up a new machine, or logging to remote servers you expect 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 very basic editor as Notepad is more enough. It can open files, edit those, and save. 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 of their respective projects, given that there’s also GNOME Builder thing. Maybe I’m wrong though.

Figure 3: Kate editor with default settings

Pretty much the same goes for Kate1, 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 editors.

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

Editor popularity chart for past five years.

This is not the most accurate data, I’ve taken it from Google Trends, and put Mousepad, Kate, and Gedit into 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 point of interest is very low. The other reason is that, perhaps, users first try 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 other competitors listed in the chart.

Another problem is 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 if not good for ecosystem. Considering that Kate has small user base, and even smaller part of that users cares to write plugins, and 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 editor to success. Most editors that will be listed afterwards 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 editors feature 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 one by one.

Sublime Text

Figure 4: Sublime Text 3

Originally, Sublime Text was meant to provide experience close to TextMate (which I will not going to touch here, because I don’t have a Mac to check it), but for 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 it’s 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 good choice aside from its speed?

• Fuzzy search.

  Sublime has this neat feature, when you can open special prompt and type 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 it’s own grammar system. This makes it supporting all TextMate supported languages, plus it’s own set of other languages, which sometimes overlap with TextMate’s grammar, but providing 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 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 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 project.

Interestingly enough none of these features are anything special for today’s editors. Many are cross platform, most of 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 of proprietary software as I can for the last 10 years. And especially when there’s 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, that 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 such approach are mostly endless. I mean, today browsers can view PDF, 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 browser is 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 concrete line, and when you scroll view, this popup window moves with that line. This popup can have it’s own scrolling capabilities, and other interactive features, such as displaying graphics, because it is essentially just an <div> tag with some display properties. As example, we can really see that in developer console inside Atom:

Figure 5: Atom’s developer console and documentation popup.

But unfortunately, as always, there’s a cost. Web interfaces are really flexible, but we sacrifice performance for this, because although 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 seem realized that in order to speed things up it needs a proper technology, so some parts (e.g. Tree Sitter - incremental parser framework, search can use ripgrep tool) are now written in native languages. There was a project that aimed to rewrite the core of 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 Java Script, but the main difference is in approach to extending and configuring the editor. Both Atom and VS Code feature plugins, written in JavaScript. Both Atom and VS Code can install plugins from respective stores. 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 editor works, while in Sublime Text and VS Code plugins mostly add features on top of how editor works. Let’s look at this screenshot of Atom:

Figure 6: Atom Editor default look

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 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 Code2 is that user 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, but 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, that adds some amazing capabilities to 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.

Figure 7: Visual Studio Code default look

Visual Studio Code on the other hand is not that hackable. Well, it is quite hackable, VS Code features 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 out of 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 rendering toolkit are basically the same as in web browser, we can add any kind of graphical interface to the editor. It can be advanced color picker, if you work with CSS styles, PDF viewer, if you’re working on documentation, 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 web is now our graphical toolkit. This is good for creating interfaces that suit your developing needs. I highly suggest you to watch talk by Bret Victor, called Inventing on Principle. It highlights the need of exploration of the domain we’re working in, which is computers, and in case of Atom and VS Code web stack.

There is another kind of text editors, which is more texty. Those embrace text as it’s 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 others TUI based editors. Let’s look at those in detail.

Behold! Vim, the king of text editors.

Vim has very long history as text editor. The predecessor, Vi, had many features that were really useful at the time, such as modes, but was 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 Vi formula. So what Vim is like? Let’s have a look:

Not like there is much here to see. Just like in case of Gedit or Kate. However, as other editors Vim supports plugins. These plugins can change Vim quite heavily. As in Atom, you can add tabs via plugin, change status line appearance, add file explorer, and tag browser, and so forth. Furthermore, like in 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 file tree here is fully interactive but is essentially text. Here’s my old Vim setup:

But 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 key benefits of Vim? I think these are quite heavy arguments:

• Vim is fast. Really fast.

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

• Vim is quite lightweight.

  Although it has 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 feature 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 much more different languages, like Lua or JavaScript.

• Vim is not generic text editor, rather it is 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 current word, you can do diw which would stand for delete inside word, and if you want to delete 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 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 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 last modification with . key. This is 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 edit text while still using Vim-like model.

Kakoune

This editor definitely is something. The main difference from Vim is that Kakoune uses object-verb system - you select first, then edit, so Vim’s dw becomes wd in Kakoune. And the main feature of 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 cursor at all. It is always a selection, and most of the time it is simply single char selection.

Figure 8: Kakoune

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 interactive development environment:

Figure 9: Kakoune with plugins

Just like in Vim, we can create 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 as a modern take on Vim. Unlike Vim, Kakoune is much simpler - it does not include window management, it does not have it’s own scripting language, and for me this was a big no-no, when I’ve first saw Kakoune. However trust me, the lack of the language is not a problem for Kakoune, and it does not need window managing capabilities at all. And Kakoune 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 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 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:

Figure 10: Select til paragraph end → select \w+count regexp → select everything up to count in resulting selections

Of course we could do it 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 wrote some plugins for Kakoune, one of which was tagbar.kak, that provides side panel with tags for 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 most weird, yet really great way to extend the editor. All editors that we’ve seen so far used some kind of a 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 very basic scripting language, called kakscript, but it has no control flow except try and catch, and only used to create basic commands. However you can go far with it, because it allows you to execute Kakoune keys, and all of other Kakoune commands. For example most indentation handling is done through searching for previous line, copying it’s indent level, adding needed amount of indentation to that level and applying it to currently indenting line. Because Kakoune features very fast regular expression language, and quite robust on its own this is one feasible approach to write 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 string like "current line is: %val{cursor_line}", and it will expand to 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 to use POSIX shell scripting environments, so it could work on all POSIX complaint systems. And with shell you can use any language you want!

Kakoune exposes it’s 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 current selection in a shell expansion as $kak_selection. And if your plugin defines some option, you can expose it to shell as well.

This allows users to build any kind of plugin without much API. We only see 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 beginning of the buffer. So if you know your session, which is PID of Kakoune, you can interact with Kakoune from outside world. This is quite flexible system, and it adheres the design of POSIX complaint 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 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’ve said that Kakoune doesn’t need it’s 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 human interface as programming interface. You see, shell is meant to be used by humans, and writing programs that manipulate 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 wrote code correctly. But not all applications are like this, and some of system 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 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 it’s central way of interaction with text. It 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 not yet sufficient to compete with Atom or VS Code, which have rich rendering system, 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 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 virtual machine, which a has 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, but 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 text editor. It has 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.

Which is, in fact, kinda true. You see, by default 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 control key is a pain point for many users. I personally remapped Caps Lock to be my Ctrl way before I’ve 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 topic instead. And this topic is Emacs Lisp.

Being 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 invisible region that is not active, but it’s 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 bitten 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 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 known shortcut, and cut regions when we want. This is 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 custom action to existing function without redefining it. Emacs Lisp has interesting way of doing this by using advices. 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 external package doesn’t respect my custom function. I can advice 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 really powerful feature, which makes it easy to patch foreign functions in a way that you don’t have to patch it again until it’s signature changed. 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 visual clone of Atom editor, because I like how Atom looks. See side by side comparison:

Figure 11: Emacs and Atom

It’s not 100% clone, though I really like how it turned out, but 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, Atom, I’ve encountered problems with quite popular plugins, that prevented my from doing my work by either not working at all, or having some bugs that made usage impossible. Never happened in Emacs. Of course some times packages break, but it gets fixed really fast, unlike in those editors.

Which one is the best?

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

• Gedit, Kate, Mousepad
• Sublime Text
• VS Code
• 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 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 cheaply to put Atom and VS Code on 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 integrated terminal.

Next goes Sublime Text, because it is on par in terms of features with firs two, much faster, but I don’t personally care for the speed much, and abilities for further customization is 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 rich rendering and thus customization possibilities are more limited. And it’s 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 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 into previous chart, because those all are not OOTB enough, but their main focus is also different. So the second group are 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 deepest customization possibilities, even deeper than in Atom. And although out of the box state of Emacs is miserable this is not it’s 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 to use 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 particular language, and if you’re living in isolated world you can even use 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 editor provides it own language. Kakoune provides a way to call shell, and Emacs has 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. Kakoune
5. Gedit, Mousepad

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

VS Code is on the first place, because it gets a lot of plugins each week, and ships decent amount out of the box, so most of developers can use it without any configuration or with really minimal one. This is important, because editor is a tool that should make us more productive. Also, I’ve found 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 the second place, but for a slightly different reasons. Emacs has a metric ton of packages shipped by default, however those are not really used or configured for good out of the box experience. It also has insane amount of packages available online, and you can find practically anything for Emacs. Hell, you can order salads from Emacs!

Vim has less plugins built in, but it has mostly only necessary ones. Those are not enabled by default either, but at least you can browse through manual and get the idea of what’s shipped. It has many plugins available online too, however I found that they either have less 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 REPL3 or Activate Power Mode.

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

Kate has more features out of the box compared to other default editors1, 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. Kakoune
5. Emacs
6. 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 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 tool why would you lock yourself to those that are at hand?

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

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

Yes, I think Emacs is the best what happened to me so far, the best editor and application platform for text related workflow. Kakoune is also 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, really powerful customization abilities, and 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’ve 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 office, that I sometimes have direct access to. Mousepad is the least interesting for me.

This concludes my kinda random thoughts on text editing tools. I hope this was at least 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 a way longer than I’ve expected.

Thanks for reading.

1. though Kate is not strictly a default editor, because KDE project usually is shipped with KWrite. Which reminds me of Windows way of doing this, since KWrite as WordPad is aimed at documents, not code. ↩︎

2. You can do this in VS Code via this plugin vscode-init-script, but it is not supported directly by VS Code so use it on your own risk. ↩︎

3. which uses Ink, which integration is broken at the time of writing this so you have to downgrade it, which kinda illustrates what I’m talking about. ↩︎