Hacker News Reader

Comment by ninjin | Hacker News Reader

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].

[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?

View on HN

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?

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

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

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"'.

> 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)

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

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.

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).

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.

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

That’s a good way to put it

This is how TECO worked explicitly. The general operation syntax is

    [count] command [argument ESC]

I have never seen direct confirmation that vi commands were modelled on TECO, but they seem too similar for it be entirely coincidence.

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.

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

One thing I found really valuable is using ed for a bit, this really helped improve my sed skills.

Message editors on BBSes were quite similar to ed. Even more limited since you didn't have the substitution command.

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

Lmgtfy

https://docs-archive.freebsd.org/44doc/usd/12.vi/paper.html

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

Reply on news.ycombinator.com