Learn Vim for the Last Time: A Tutorial and Primer
danielmiessler.com
danielmiessler.com
Its a trade-off; I'm less efficient with vim than I could be, since it has so many more powerful features over standard vi. The flip side is that I can go back to those older systems and feel comfortable within a couple of minutes, without getting frustrated at the installed vi editor missing the vim features that I otherwise would have come to depend upon. I traded off using powerful features that could speed coding (if I would just memorize them all), for the flexibility to be able to jump between (similar, but different) systems much more easily.
Of course, those systems are not as in as much common use anymore due to the end of the UNIX wars, so the value of that style of working is now resulting in diminishing returns.
I'd like to be able to change, but like many older programmers, we often like to stick to what we know, as long as we can get the job done quickly and with minimum fuss.
I can use vi as comfortably as vi can be used. I wish that vim's features were there, but that doesn't make me any less adept at using even the most minimal build of vi.
Really, this is because vim itself is generally stuck under the ceiling if vi's keymap. Apart from a very slim amount of additions, there isn't any difference between the interface of vi and vim.
Vim makes a point to keep that backwards compatibility. In fact, most vi implementations you use are simply a heavily stripped down certain of vim.
This may be true today, but certainly was not on the aforementioned systems back in the 1990's, when I learned UNIX. Even in the early days of Linux, I don't believe vim was as popular, and frequently the distribution shipped with an alternative (nvi, elvis etc). In fact, I probably learned most of my limited vi subset back in the late 1980's on XENIX come to think of it - and that was extremely limited from memory.
Unfortunately I am also relatively lazy and dumb compared to the average HN user. The only real concession I have made to vim is to use the cursor keys for movement instead of the traditional vi cursor control commands, because it helps when switching between desktop based editors (eg. Notepad on Windows, the equivalent Gnome editor, Visual Studio etc). And also because I am unlikely to go back to those old UNIX systems again.
Of course, I am half expecting someone to come along in a moment and tell us we are both wrong anyway, and that we should be using Emacs.
Effectively: as soon as the file is opened, I'd remain in the text entering mode (however it is called in vim terminology) pressing any arrow key (or maybe even the pg up, pg down etc) would exit that mode (implicit Esc) perform the expected movement and at the end automatically return to the starting mode.
I believe I was able to achieve it then by assigning the whole sequences (e.g. Esc, movement, i) to be played as I pressed only one of these keys, and automatic i after the file open, and I don't know if all this is possible now with vim, the little I've tried to find I haven't found that functionality. I'd even claim that having something like this would make vim much less frustrating for the casual users. What I'm sure is that I don't have any written record what I've did then -- it was "works for me" then and for that environment.
Maybe somebody knows more about this? I'd like to be able to achieve such a behavior in Vim even if it's the opposite of what people in these tutorials try to teach people to do, as an example, I haven't understood what this does (it is not clearly explained here except claiming "the <Esc> key for leaving insert mode is, in my opinion, rather antiquated. Vim is about efficiency, and it's hardly efficient to leave the home keys if you don't have to. So don't.") but it seems to me, nothing I'd like:
> inoremap jk <ESC>
I'd argue that not having to even change the modes explicitly at all is more efficient than optimizing the key with which you permanently change the modes. Somebody would say "but then you can't do these nice number-movement to move number of times" -- I don't care, it takes more time to count or to try, err and undo when the number is wrong, than to just use the plain keys. It was not so when editing from the terminal over 300 baud lines, which was the original use case for these commands, but nobody edits over them today.
More importantly, you don't get undo, since that is action based in vi, and everything from entering insert mode to leaving it is a single action.
You are better off using nano or similar, which is becoming (rightfully) more available than vi.