
Learn Vim for the Last Time: A Tutorial and Primer - poindontcare
https://danielmiessler.com/study/vim/
======
nineteen999
As I grew up working with both Linux and a bunch of legacy UNIX systems as
well (Solaris, AIX, HP-UX, Tru64), over the years I've ended up using only a
subset of vi commands that work with both SVR3/SVR4 style systems (tradional
vi) and Linux (vim). A similar thing happened with my shell scripting style;
I'm prone to writing shell scripts that exclude bash-isms and conform more to
standard Bourne shell syntax, since I know that they will work pretty much
anywhere.

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.

~~~
thomastjeffery
As a long time "expert" vim user, I have found that that fear you expressed -
the inability to use vi comfortably after using vim more completely - is ill-
founded.

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.

~~~
nineteen999
> 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.

------
acqq
I believe to remember that a few decades ago on some Unix variant I was able
to use some kind of vi with some settings where I was able to configure it for
not having to do Esc at all for the movements through the text when using all
the arrow keys of the terminal I've used and also not having to press any key
to start typing the text after these movements and only had to do Esc to type
in the non-trivial (i.e. non-movement) commands.

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.

~~~
dcassett
On Linux you can use the evim command to start up in insert mode, or to stay
in insert mode in gvim, :set im

~~~
acqq
It seems that startinsert added to the .vimrc is also a possible start.

------
croh
[https://laymanclass.com/vim-essential-setup-to-boost-your-
pr...](https://laymanclass.com/vim-essential-setup-to-boost-your-
productivity/)

