My Personal Reflection on the Editor Wars
Ishe Chinyoka
- 5 minutes readTable of Contents
There was a time when mentioning Emacs and Vim positively in the same sentence felt almost taboo. The internet seemed to insist that one had to choose a side. You were either an Emacs person or a Vim person, and once you crossed that line, there was no going back.
I never quite fit into that story.
My own journey into text editing did not begin with Unix traditions or decades of editor folklore. It began with a much simpler question:
Can I use this editor effectively?
That question shaped my choices far more than community allegiances ever did.
My First Love: Emacs on Windows
Long before I became a Linux user, I spent years on Windows. During that period I learned Emacs.
Perhaps that sounds unusual. Many people discover Emacs only after moving to Linux or BSD. For me, it happened the other way around.
What attracted me was not its history, nor the endless jokes about it being an operating system disguised as an editor. It was its accessibility and its flexibility. I found an environment where nearly everything could be customized, automated, or extended. The editor invited exploration rather than merely providing a place to type.
At that stage I judged editors by a practical standard rather than an ideological one.
Then Linux Changed My Perspective
When I switched to Linux in 2018, something interesting happened.
Like many newcomers, I started editing configuration files with Vim because it was already installed. At first it was simply the editor that happened to be there.
Then, gradually, I began to appreciate its design.
Vim’s verb-action approach fascinated me. Editing became less about pressing shortcut keys and more about describing transformations.
Delete a word.
Change inside parentheses.
Select until the next comma.
Repeat the previous change.
The editor almost felt like a language for manipulating text rather than a program with menus and buttons.
The more I used it, the more natural it became.
Today I spend most of my editing time in Vim—not because I rejected Emacs, but because my daily work happens to fit Vim’s editing philosophy remarkably well.
What Really Matters in a Text Editor?
Over the years I have discovered that my requirements for an editor are surprisingly modest.
A good text editor should satisfy four important qualities.
1. It must load plain text
This sounds almost too obvious to mention, but for a textsmith, plain text is the foundation.
Configuration files.
Markdown.
LaTeX.
Shell scripts.
Source code.
CSV files.
Logs.
If an editor treats plain text as a first-class citizen, it already earns my attention.
2. It should support regular expressions
Search and replace is where simple editing becomes real text processing.
Once an editor understands regular expressions, repetitive work suddenly becomes elegant.
Whether correcting thousands of lines, restructuring data, or cleaning imported text, regex transforms an editor from a typing tool into a productivity tool.
3. It should be extensible
Eventually every serious textsmith wants the editor to do something its creators never imagined.
That is where extension systems matter.
Emacs has Emacs Lisp.
Vim has Vimscript and now Lua.
VS Code has its extension marketplace.
A living editor is one that can grow together with its users.
4. It should have excellent documentation
Perhaps the most overlooked feature of all.
An editor that can be hacked but cannot be understood is only half useful.
The greatest editors have thriving documentation, books, tutorials, mailing lists, and communities that encourage curiosity.
Good documentation turns software into a craft.
Why VS Code Interests Me
These days I also find myself increasingly fascinated by VS Code.
Not because I plan to abandon Vim.
Not because it is fashionable.
Rather, I want to understand why it has taken both programming and technical writing communities by storm.
There must be genuine ideas worth learning.
The extension ecosystem is remarkable.
Its Language Server Protocol has reshaped how editors provide intelligent programming assistance.
Its integration with Git, terminals, notebooks, and remote development demonstrates that modern editors are becoming platforms rather than standalone applications.
Even if I never make VS Code my primary editor, I believe there is value in understanding why millions of developers have embraced it.
Every successful tool teaches us something.
Beyond the Wars
The editor wars have always been entertaining.
They produce memorable jokes.
Entire websites have been dedicated to them.
Like the Unix shell debates or the Linux distribution wars, they form part of computing culture.
But they can also become distractions.
A text editor is ultimately a tool.
No carpenter becomes skilled simply because he owns an expensive hammer.
Likewise, no textsmith becomes productive merely by installing the editor that happens to be fashionable this year.
Skill comes from study.
It comes from learning the commands.
Reading the manual.
Writing macros.
Exploring extensions.
Making mistakes.
Developing habits.
The editor matters.
But the craft matters more.
Keep Learning
Perhaps the greatest lesson I have learned is this:
Never dismiss a tool you have never seriously studied.
The editor you ignored yesterday may solve tomorrow’s problem.
Had I dismissed Vim while using Emacs on Windows, I would never have discovered an editing model that now feels wonderfully natural.
Likewise, if I dismiss VS Code simply because I am comfortable with Vim, I may miss ideas that could improve my workflow—or at least broaden my understanding of what modern editors can become.
The mark of a textsmith is not loyalty to a particular editor.
It is curiosity.
Learn your tools deeply.
Respect the choices of others.
Keep an open mind.
After all, we edit the same plain text.
Everything else is just a different way of reaching it.