The original source code of the vi text editor, taken from System V(github.com)
github.com
The original source code of the vi text editor, taken from System V
https://github.com/Cube9999/vi
54 comments
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.
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
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?
Emacs had undo tree since as long as I can remember
Yes, and I still get lost in it, it's one of Emacs' most confusing features.
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.
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Un...
[2] Here is a screenshot from 11 years ago: https://www.emacswiki.org/emacs/UndoTree#h5o-5
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Un...
[2] Here is a screenshot from 11 years ago: https://www.emacswiki.org/emacs/UndoTree#h5o-5
No, I meant the built in one... Not sure why is it confusing always just worked for me. Thought vim undo was similar, maybe I was mistaken.
> My biggest struggle has been finding good resources to learn the "proper" way to use it
Why stop at vi? Go all the way and re-orient your entire lifestyle around Unix text processing: vi, awk, sed, troff, and sh.
https://www.oreilly.com/openbook/utp/UnixTextProcessing.pdf
Why stop at vi? Go all the way and re-orient your entire lifestyle around Unix text processing: vi, awk, sed, troff, and sh.
https://www.oreilly.com/openbook/utp/UnixTextProcessing.pdf
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.
Oh, man. That book really brings back memories. That was my introduction to text processing back in the day.
> 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"'.
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.
(1) https://www.texteditors.org/cgi-bin/wiki.pl?FRED
(2) https://en.wikipedia.org/wiki/Stevie_(text_editor)
(3) https://en.wikipedia.org/wiki/Elvis_(text_editor)
> 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.
(1) https://www.texteditors.org/cgi-bin/wiki.pl?FRED
(2) https://en.wikipedia.org/wiki/Stevie_(text_editor)
(3) https://en.wikipedia.org/wiki/Elvis_(text_editor)
[deleted]
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
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.
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.
Yes, the “vi way” is to get out of insert mode as quickly as possible. You hit esc as son as you stopped typing and paused to think.
I love vim, but vi is too spartan for me.
I love vim, but vi is too spartan for me.
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>.
This is how TECO worked explicitly. The general operation syntax is
[count] command [argument 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.
That’s a good way to put it
This is not a vi tutorial per se, but IMO it's a pretty good overview of the vi philosophy: https://stackoverflow.com/questions/1218390/what-is-your-mos...
> 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
Start with the original tutorial, An Introduction to Display Editing with Vi.
Start with the original tutorial, An Introduction to Display Editing with Vi.
I've had the same issues but for ed. I need some good example usages, I mean it must've been used for a while but it's hard to find resources...
Michael W Lucas has his Ed Mastery [1]. I am not sure how good it is as I am yet to read it, but I have enjoyed his OpenBSD books.
[1]: https://www.tiltedwindmillpress.com/product/ed
[1]: https://www.tiltedwindmillpress.com/product/ed
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.
edit: typos
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.
edit: typos
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.
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.
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)
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)
As Mitch Hedberg once said,
:2s/wa/i/gThis is what it looked like about 7-8 years earlier: https://github.com/dspinellis/unix-history-repo/blob/BSD-1/e...
the guts of visual mode: https://github.com/dspinellis/unix-history-repo/blob/BSD-1/e...
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.
This is a significantly evolved version. The Berkeley copyrights are 1981, so it's probably from 4BSD.
Indeed, the History of Documented Unix Facilities [https://github.com/dspinellis/unix-history-man] says a vi(1) man page first appeared in 2BSD, and vi is implemented (as part of ex, with a 1979 copyright) in 2BSD src/ex, with the main routines at src/ex/ex_vmain.c: https://github.com/dspinellis/unix-history-repo/blob/BSD-2-S...
This code implements the most important feature of the editor in question: https://github.com/Cube9999/vi/blob/master/vax/ex_cmds.c#L45...
I was curious how big it was.
It's 14,801 lines of C and 640 lines of C Headers, with 4,722 and 589 lines of comments respectively. There's also 285 lines of assembly.
It's 14,801 lines of C and 640 lines of C Headers, with 4,722 and 589 lines of comments respectively. There's also 285 lines of assembly.
Looking in the source, there appear to be implementations of bcopy (in Vax assembly!!) and printf. Didn't SysV have a libc at this point?
I think Joy coded on BSD. So.. this is surely a backplate, no?
Didn't Bill Joy lose the original source he wrote at Berkeley?
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.
You're not the only one! Not until I saw your comment did I re-read to check...which helped answer my question "Why would the Saturn V need vi?"
It's been a long day.
It's been a long day.
[deleted]
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].
[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?