Clickbait titles aside, I actually think that Emacs is a terrible editor out of the box. So, how come I use it anyway? In this post, I will contrast Emacs with VI(M) in order to point out some important factors in choosing the perfect text editor.
When you open VI(M), you have one of (if not) the best editors ever created at your fingertips. And I mean that in the purely editing sense – getting what you have within your head transformed into text on a computer. From the ergonomics to its modal editing paradigm, there is hardly a thing that one may complain about in this regard. All of the important key combinations stay on the home row. When you open up Emacs, on the other hand, its ergonomy is one of the first factors that you notice as a lack. Case in point, there is even a term for the injury that Emacs users get by excessive usage of key-chords with the “Control” key: “Emacs pinky”.
Another benefit of VI(M) over Emacs is its mere speed. VI(M) is incredibly lean and terminal-based by design. The only time you have to wait on VI(M) is when a command is executed without asynchrony (a flaw which we will discuss later). Emacs is simply bulky; it has way too many packages and functionally included by default and, despite what some may argue, it does not really adhere to the UNIX philosophy as much as VI(M) does. Emacs users, including myself, constantly try to optimise the speed with which Emacs starts and works. We mostly go about it by using the included daemon and various start-time optimisations. VI(M) users never even think about start times, as they are so insignificant that it’s practically instantaneous.
Despite the amazing speed of editing that VI(M) offers, however, a glaring flaw becomes apparent when you try to extend it beyond any basic plugins. Its scripting langauge has generally been accepted as bad within the community. This is easily proven by the mere existence of incredibly successful projects such as NEOVIM which aim to embed other scripting languages in VIM and the simple fact that vimscript has had a significant (not backwards compatible) overhaul just recently in VIM9.
However much this may have improved the situation, Emacs has an undoubtedly better scripting language in elisp, which has brought alongside it a prosperous community of package creators. There’s org-mode, AUCTeX, magit, mu4e and many other projects which make Emacs a better IDE than any IDE. And most importantly, there is evil-mode, which makes Emacs almost a better VI(M) than VI(M) itself. Furthermore, the paradigm of elisp, as a functional programming language, really permits amazing modality wherein one has different bindings and environments for each context.
Additionally, Emacs has great asynchronous execution which VIM didn’t have until recently. So, despite the speed issues that one might encounter with Emacs, whenever working in a real situation, processes such as compilation may be run in the background which ultimately ends up being faster than VI(M). You may notice this when writing and compiling LaTeX documents, for example. You may hit the binding for compilation and keep writing. Also, you can run a make command and switch to the next thing you have to work on without waiting.
I use Emacs because despite its flaws because its very nature fixes said flaws. It does not have to be as it is out of the box; in fact, it can be very different due to its extensibility. Hence why I still use it in my day-to-day text-editing. And even if I sometimes still think about VI(M) and remember its simplicity and speed; I get most of what I miss anyway, in Emacs’ emulation of VIM. Finally, until VIM or NVIM manages to surpass Emacs with an vivid extensible ecosystem, I think I shall remain an Emacs user.