Why Vim is the best text editor

gistfile1.txt

The core idea of Vim is the very essence of the Unix Philosophy:

> Even though the UNIX system introduces a number of innovative programs and
> techniques, no single program or idea makes it work well. Instead, what makes
> it effective is the approach to programming, a philosophy of using the
> computer. Although that philosophy can't be written down in a single sentence,
> at its heart is the idea that the power of a system comes more from the
> relationships among programs than from the programs themselves. Many UNIX
> programs do quite trivial things in isolation, but, combined with other
> programs, become general and useful tools.

https://en.wikipedia.org/wiki/Unix_philosophy#The_UNIX_Programming_Environment

So there will be no neat trick or single feature that makes Vim the best
editor. The reason it is the best is because of the infinite composability of
the tools that it provides to you. Those tools form a language which you can
use to describe the process of editing text.

These tools can be broadly split into the following areas:

* Movement
* Change
* Reference
* Replay

The very beginning of using Vim is about learning to move and learning to
change.

Most people start by learning the arrow keys (spit), i, <esc>, x and :wq. In
this proto state they are no better than they were when using cheapest nastiest
oldest text editor available.

If they stick with it then they can start to learn about the different ways to
move - by word (wb), by paragraph ({}), to the start or end of a line (0^$), by
page (ctrl-u, ctrl-d), by searching (tTfF/?), and the different ways to change
(too numerous to list but at the very least c/C/d/D/dd/a/i and perhaps an ex
command like :s). They should have started on the use of references by yanking
(y/yy/d etc) and pasting (pP) and possibly even using the '.' replay operator.
Now they have matched their old editor.

These initial stages feel like failures, but not because they just don't have
enough tools to compose well. It is perfectly possible to edit text like this.
If you stuck at this point then it would be a mystery why Vim was rated so
highly, as everything you could achieve in Vim could be achieved in another
editor (and probably faster too).

Macros are probably the first really amazing thing that Vim offers. They may be
the single feature you want so to show off.

They are the first multiplier that Vim offers. If you can move well and edit
using appropriate actions then your macros will be more powerful. A macro
should be treated as a template of the change you wish to make to the document.
When you run that macro you apply that template to your current situation. With
this you move from editing text to transforming text.

Macros themselves can be composed with other commands. You can run a macro over
every line of a visual selection, and you can repeat a macro.

At this point Vim is very strong. As a programmer you are unique in that you
get to deal with highly structured yet differing text on a constant basis. With
Vim macros you can express only the differences that the final text will posses
and then transform the text into it's final form.

For example: A Java POJO class has a name, a constructor and some fields with
getter and setter methods. The only thing that needs to be expressed is the
names of those things. Once you have them you are able to generate the rest of
the code using macros. I would probably have one macro that created the class
(with constructor) from the class name and one macro that created a field,
getter and setter from a field name.

Now there are IDEs that can do that sort of thing. They have a special built in
button that might as well be labelled "Make Rocket Go Now". With Vim you
composed the macro by doing the thing you wanted to one single time and
recording it.

The real magic of Vim comes with the last two stages. However those phases
would be empty without the full range of movement and change already available.


The realisation of the power of these is somewhat parallel to the way a young
programmer might transition from "I have code and it operates on data" to "code
is data and data is code and I can apply the same techniques to both".

Commands are text and text is commands
(I has grammars, yes)

When you yank, you yank into a register. You can reuse that text in many ways.
When you record a macro what you type is written directly to a register. You
can play a macro to repeat the actions.

If you ever feel like becoming insane then start pasting macros and editing
them. Then yank text and run it as a macro. These final techniques are beyond
what any other editor could really dream of. They are also beyond my
comprehension really. The best thing is for them to be locked up in utilities
and tools. The ctags (see :help ctags) tool is such a thing. That creates a
tagfile which contains all notable references in your code (things like class
and method names) and describes how to reach them by writing a macro that will
take you there.

I believe that vim macros make the process of editing text in vim turing
complete. I present the following demonstration:

To run this do the following.
 * Copy the text below into a new vim buffer
 * Move to the first line and yank it with yy
 * Execute that with @"

j0"ay$jj@a
ihello

This adds a 'hello' to the page. The hello is contained in register a, however
you ran the default register ("). This means that a macro can trigger another
macro. You cannot do this normally when recording a macro as pressing q or @
will stop the macro.

To run this do the following.
 * Copy the text below into a new vim buffer
 * Move to the first line and yank it with yy
 * Execute that with @"

j0"ay$majj@a
'aj0"by$''@b
ihello

This also adds a 'hello' to the page. The hello is contained in register b.
This shows that macros can invoke macros which invoke macros. How deep does the
rabbit hole go?

j0"ay$j"byy@a
"bp@a
hello

To be turing complete this would require that the stopping conditions for macros only halt the current macro instead of halting all of them. Unfortunately this is not the case:

j0"ay$j0"by$jj@a@b
0fz
yyp

hello world

Here the first macro searches for the z letter in the hello world line. It does not find it. If only that macro was halted then the second macro would still run, duplicating the line. It does not.