I have experimented a bit with using vi(1) as my main editor to better understand where vim(1) came from. Overall, it is a very functional editor with my rather minimal `.exrc`:
set autoindent
set ruler
set showmode
My biggest struggle has been finding good resources to learn the "proper" way to use it as pretty much any search will land you with vim-isms and no one "serious" really uses vi(1). Matt Widmann did write a few good pieces though [1,2].
The only seemingly unsurmountable hurdle I can think of is the inability (as far as I can tell) to bind control key chords to movement in insert mode. But maybe I am simply "using it wrong" and need to adapt my thinking to suit the tool?
One thing to note: the author of the linked blog posts uses nvi, which is
not exactly vi either (but rather, a reimplementation of vi to circumvent
copyright issues originating from ex/vi being based on ed).
It gets very close, but there are some extra features (e.g. multi-window,
multi-undo) and subtle incompatibilities in some cases.[1] Either way,
I suppose its feature set is much closer to that of traditional vi.
> My biggest struggle has been finding good resources to learn the "proper"
way to use it
I would recommend reading through the manpage, I've learned a lot doing that.
Some tips:
* Most line-oriented operations in vim that are missing from vi can be
done using filter commands. e.g. you can emulate vim gww as !!fmt.
* vi has no cib, dib, etc. But it has %, which is usually good enough.
* Visual mode is vim-only, but marks come from vi (which, in general, can be
used for the same purpose).
* If you're using nvi, you have multi-level undo too (try u.....). In
traditional vi, the best you can get is "1 "2 ... for deleted text (and
U for restoring saved lines).
> The only seemingly unsurmountable hurdle I can think of is the inability
(as far as I can tell) to bind control key chords to movement in insert mode.
Yeah, vi is fundamentally a modal editor, if you want key chords you're
probably better off using emacs. (Or *vim, I guess.)
That said, you can define abbreviations, which work in input mode. e.g. I use
an adapted version of the HTML abbreviation file from
https://thomer.com/vi/vi.html#macros. (Most links are dead, unfortunately. But
the HTML abbreviations work.)
[1]: At least in my nvi version (nvi2):
iabcd^[:s/b/^V^M^M
places the cursor on the line with a. Heirloom vi and vim both place it
on the line with cd. Probably an nvi bug.
In vi (as opposed to vim), you can't just move around in insert mode. An insert/append/change action is limited to one continuous string; the undo mechanism also cannot handle anything more than that. It was pretty mindblowing to me when I discovered vim could do that, it's just way outside the concepts that I grew up with in vi and it still confuses me a bit.
I started using PC in WinXP era, so vim's multi-undo wasn't very surprising to me. But when I first learned about undo tree - it blew my mind in pretty much the same way.
If I'm not mistaken, undo tree in 2023 is still almost an exclusive feature of vim, even the most popular IDE - VScode doesn't have a way to recover state before undo + typing, aka GURQ https://github.com/zaboople/klonk/blob/master/TheGURQ.md
Oh, multilevel undo was something that was not hard to fathom and that I yearned for for years. It was the concept of a composite action (edit, move to somewhere else, edit something) while not leaving insert mode that just didn't fit into my idea of what vi was. Would a single undo step undo only one part of that or all of it?
The built-in undo[1] in Emacs is confusing but I think parent means the undo-tree package.[2] The package is super intuitive, you navigate the tree with the arrow keys and you can pull up the diff of each change if you want to.
I remember jumping a bit when I saw the authors: Dale Doughterty and Tim O'Reilly. In all honesty, I should spend more time with the book as I have only used it to get a good introduction to troff in the past. Another tool which it is difficult to "modern" documentation for.
> bind control key chords to movement in insert mode. But maybe I am simply "using it wrong"
Is that what you do in vim? I use vim, but haven't come across that before.
It does seem consistent with the basic concept not to have or to need insert mode bindings (of any kind, except return to normal mode, since all you're doing is inserting the characters corresponding to your key presses) to me, so maybe '"using it wrong"'.
> I have experimented a bit with using vi(1) as my main editor to better understand where vim(1) came from.
> But maybe I am simply "using it wrong" and need to adapt my thinking to suit the tool?
Maybe a better way to think of it as all of these struggles are WHY vim exists? Mission accomplished, go back to vim :-)
I started using fred (like ed on steroids) in university(1), graduated to vi during workterms, eventually used stevie(2) and elvis(3) for a few years before landing on vim in the 90s.
vim has moved so far past all of those that it's like driving a model T to understand where your tesla came from.
Even the “vi compatible” mode in Vim does things quite differently.
If you want something closer to the original Vi experience, the lesser known “nvi” (not to be confused with “nvim”) follows the original UNIX behavior much more closely.
It seems to be the default in BSD and some Unix distributions. Last I checked 10+ years ago Debian shipped its base system with nvi. Many many years ago (20+) I actually used nvi in a programming competition because the only alternative was a horribly buggy IDE thing (the host organizers was trying to switch from windows to Linux as the default env but a bunch of support wasn’t quite there yet). nvi is actually quite usable as long as you’re not too deep in the Vim-isms
Most mainstream Linux distributions (including Debian), as well as macOS use vim as the default vi. As you noted, the BSDs still default to (n)vi. Another place where it vi (not vim) is still used is in embedded systems and stripped down/rescue/installation, which often use Busybox (which includes a vi implementation).
To add to war stories: actually knowing vi commands saved my life once because I could not mount my file system (can't remember why) on my bsd and I only had access through a serial line terminal. Basically I figured out that ed was the only thing usable and it basically has the same commands as vi with the big difference that I could only effectivly look at one line at a time. Using a dumb terminal was quite an experience (the vt520 I used on the port actually supported much richer interactions). It was the one instance when I suddenly understood why also vim commands worked how the do (I think I am using vim since the old Amiga days and therefore never considered another editor due to my muscle memory).
Not a true war story but I used to use "open mode" in vi a lot when on a 1200 baud modem. It's like a line-based visual mode; if you have a smart but slow terminal, you can move around in the current line with h and l etc., but when you move up or down a new line is printed and you move within that line now. The i, a and c commands work more or less as normal. A few times I got into open mode in a dumb terminal, which is an even more special experience: vi will print backslashes when you delete characters and you have to count them yourself (I may misremember things slightly here). You enter open mode using the :o(pen) command.
Later I discovered that you can use visual mode with a small number of lines (:set lines), which was much more pleasant. Also I got a 14k4 modem which solved most other problems.
In my view the "vi way" is to forget about a insert as a mode and instead, treat i(nsert) and a(ppend) as commands, with the to be inserted string as an argument, terminated by <esc>.
One consequence of this in nvi (& IIRC vi) you can do <n>i<txt><esc> to repeat <txt> <n> times, just as you can repeat most any command with prefixing it with a count.
I think I learned the most about using vi when I worked with an old timer who still used ed. I thought she was crazy at first but watching her edit source code was like watching a wizard cast spells.
Learning to edit primarily via ex mode in vi and vim (commands that start with a ':') is the true vi super power in my opinion.
I had to learn ed years ago to configure a device that only had a serial port (it didn't run unix or termcap, but they ported ed for configuration purposes). Every once in a while my machine gets bogged down enough that I can pull up ed and make changes faster than vi (vim?) can load.
I had to use ed once in a very minimal rescue environment. I had never used it before, and I also only know vi in a very basic way (emacs is my daily driver).
It took some study of man pages and trial and error to achieve what I needed, but I was able to get it done.
I used ed for a few months long ago, working with a mainframe Unix-emulation environment that didn't have character I/O working yet, only line-by-line from the host OS. It taught me how to use regular expressions effectively, since they were the only way to make changes within a line. I think I still do a greater fraction of editing with RE operations than most people.
I know there are Linux distributions now that don't even include ed by default, even though it's in POSIX and occasionally used in scripts.
learned vi when I had to develop on a IBM RS6000 with AIX 3 (or 4, but we had to support AIX 3 as well) around 2008.
best shell available was ksh, and the only really usable mode was vi mode.
in addition the only worthwhile editor available on this system and customers was vi. (IIRC emacs was obtainable but not installable on customers machines, and heck of a lot slower than vi)
Uh... the "original source code" for ex visual mode was distributed in the original BSD drop in 1978. The AT&T tree didn't get it for a few years at least.
This is a significantly evolved version. The Berkeley copyrights are 1981, so it's probably from 4BSD.
Joy coded good bit of BSD, not just coded on. As I recall, vi predates the first BSD release; I believe Joy was working on AT&T Version 6 Unix, since that was the basis for 1BSD.
I misread “System V” as “Saturn V” and was sitting here thinking “there’s no way that timeline lines up”. Saturn V rockets stopped being used in 1973, vi was released in 1976. Not as far off as I would have thought.
[1]: https://mattwidmann.net/notes/modern-nvi-mappings
[2]: https://mattwidmann.net/notes/entering-control-key-chords-in...
The only seemingly unsurmountable hurdle I can think of is the inability (as far as I can tell) to bind control key chords to movement in insert mode. But maybe I am simply "using it wrong" and need to adapt my thinking to suit the tool?