[Neo]Vim
The “Lua revolution” makes everything even more a mess. Some stable arrangements will eventually emerge from the bullshit-mill of enthusiastic amateur monkey-patching, we just have to wait for a while.
The main problem is that very enthusiastic but also very amateur coders just copy-paste snippets they do not fully understand from one another (literally) and those who “design” APIs never think more that a few seconds, if at all.
The old times (the golden age) when very few programmers with required deep math background used only list structures are gone forever.
No one novadays is carefully designed a call-site of an interface, specifying which arguments are optional, what default values are, etc. If you miss an argument in an untyped dynamic language “nothing happens”, it continues silently without an error.
Principles
[Neo]Vi[m]
is great (plain and simple) because it uses a pattern language (similar in
its nature to regular expressions) to “talk” about the contents of a text file,
and systematically binds single-letter commands (with optional uniform prefixes) to particular actions on a
common patterns.
The key to deep understanding is systematic (and the resulting uniformity). This
emergent (or evolved,
literally) system is what makes [Neo]Vi[m]
great.
The fundamental (and rather obvious) principle is that one “thinks in terms of” and “acts upon” various parts and chunks of text (depending upon a particular context), NOT single characters.
In [Neo]Vi[m]
one should NEVER use arrow keys or jkhl
. This is a consequence of
the wrong way of thinking - at a single character level (H
and L
, are much more useful).
A pro moves with increasingly larger chunks of text - words, whole sentences, paragraphs and in the context of a programming language - with distinct chunks of code, usually consistent with indentation and formatting.
Neovim
has a generalized notion of tree-sitter
based textobjects (while simple
textobjects were available in the classic Vim
).
Systematic
It seems that there is not much one can do within a text file - just moving into
this or that direction with increasing or decreasing “steps”.
w
, W
, }
etc. or b
, B
, {
~ or, lets say 0
, $
. The e
command is sibling of w
.
Notice that there is a systematic difference between what a capital letter command does relative to what does the lower-case counterpart.
Not just that, but these “steps” above act as modifiers for commands such as c
,
d
, y
, etc.
And there are universal numeric modifiers, so 3w
means 3 words and y3w
means
yank 3 words. and 3yy
would be yank 3 lines.
This emergent and then evolved system is what makes [Neo]Vi[m]
unique and being
emulated within other editors.
To understand and learn it one has to start with these fundamentals. Everything else, due to being systematic is almost self-evident and one’s informed guesses would almost always turn out to be valid ones.
Modern neovim
is big. It is not wast as modern Emacs
, but nevertheless.
And, of course, using vi
with arrow keys, just like, lets say SublimeText
or VSCode
,
defies the very meaning of using vi
. No wonder it feels awkward. In fact both
vi
and Emacs
should be deeply understood and mastered and being used depending
upon context (vi
is great for a quick, “in-place” modifications of configs or code, while Emacs
is
great for long writing sessions, and one actually never exit emacs
).
This notion is deeply related to the notion of coding in one (may be great) language just like they code in another (which may be just low-effort, never deeply researched amateur kitchen-sink crap).
Both vi
and Emacs
are “ancient traditions” worth being familiar with.