For me, my introduction to vi came with my introduction to working on a CRT (which is what I think we called screens) after years with paper terminals and ed. Wow, it was so great!

But, vi has a fundamental flaw: It's modal. For example, typing an "a" might enter the character "a", or it might initiate append mode. Having worked with computer beginners for about 50 years, I can say with assurance that this is very difficult to learn. We encountered this as early as the mid-1970s when we were trying to get mainframe programmers to use the Programmers Workbench.

Other editors didn't work that way. I think emacs was non-modal, although I never used it. (Could be wrong.)

That said, there's no question but that vi could be learned and, once learned, that it was extremely productive. If a program operates consistently, it can always be learned no matter how poor the UI is. This is not to diminish Bill Joy's accomplishment and not to acknowledge that he was severely limited by the hardware available to him. (Richard Stallman had a much better terminal.) But, sadly, vi continued to be promoted long after the hardware improved. It's very hard to dislodge something so entrenched!

Much of UNIX was that way: Criticisms of its UI (notably Don Norman in 1981 or thereabouts) were refuted by those who had already learned UNIX. I recall that it was Mike Lesk who responded directly to Don Norman. (My memory is really stretching here.) Easy-to-learn and easy-to-use are very different, as we now all know.

Marc

On Fri, Jun 7, 2024 at 8:44 AM Will Senn <will.senn@gmail.com> wrote:

Well, I really dove into using vi by way of nvi this past week and I
have to say... the water's fine. It turns out that vi is a much simpler
editor to understand and use (but no less powerful) than it's great
grandchild, vim. To be fair, vim is an interesting editor and having
used it off and on since the mid '90s, it's very familiar... but its
powers? difficult to attain.

vim stands as an excellent example of just how far you can take a
product that works, keeping its core, but expanding it in all
directions. No matter how much I tried to grasp its essence, it alluded
me. The online help files seemed inscrutable to me, mixing environment
settings, ex commands, ex mode commands, vi motions, insert mode
commands in ways that seemed quite confusing to me. I know that I'm
probably among a select few vim users that love it without really having
a clue as to how it works. My best resource has been the web and search,
but of late I've been wanting more. That's what drove me on this quest
to really dig in to how things used to work and nvi is the best
surrogate of the old ways that I could find (well, excluding heirloom
vi, the traditional vi, which I've confirmed works pretty much the same
way as nvi, with lisp support and without a few nice-to-haves nvi has).

Anyway, here's something I worked out, after much travail - vi appears
to be all about modes, movement, counts, operators, registers, and
screens (which I found very weird at first, but simple in retrospect)...
with these fundamentals down, it seems like you can do anything and I
mean anything... and all of the other functions are just bolted on for
the purpose of making their specific tasks work.

Getting this out of the existing documentation was a mess. Thankfully
the nvi docs (based on the 4.4 docs) are much slimmer and better
organized. Even so, they make assumptions of the reader that I don't
seem to fit. Take motions as prolly the most glaring example - all of
the docs I've ever seen organize these by logical units of text (words,
paras, etc), personally and apparently persistently, I think of motion
as directed, so it took me a lot of experimentation, head scratching,
and writing things out several times in several different ways to
realize I could represent the idea on a single notecard as (some
commands appear in multiple lines):

Leftward motions - [[, {, (, 0, ^|_, B, b, h|^H
Rightward Movement - l|SP, e, E, w, W, $, ), }, ]]
Upward motions - 1G, ^B, H, ^U, -, k | ^P
Downward motions - G, ^F, L, ^D, ^M | +, j | ^J | ^N
Absolute - | G
Relative - %, H, M, L
Marks - m, ', `, '', ``

Keeping in mind that movements left-to-right are - section, para,
sentence, line, text, word and endword (big, and small), and letter. And
up and down are - file, screen, in screen (HML), half-screen,
chars-in-line, and line. For me, this inversion from units of motion to
direction of motion put forty some-odd commands in much closer reach for
me. Looking back at the vim documentation, I see how its sheer volume
and the way it is organized got in the way of my seeing the forest.

Thankfully, in nvi, there are two incredibly useful ex commands to help
- exu[sage] and viu[sage]. I simply printed these out and worked with
them making the experimental assumption that they would serve as a
baseline that represented the full capabilities of vi... and sure
enough, after working and working with them, I am pretty confident they
are sufficient for any editing task. Wow, who knew? I loved vi, but
now, I'm starting to really appreciate it's simplicity?! I can't believe
those words are coming out of my mouth. I never thought of it as
simple... those movement commands were far too numerous as I understood
them.

Are there things I miss from vim? Sure, I miss command line completion
in ex mode, I want my help text to appear in a window where I can
search, I would like better window control. But, I think I'll stick with
nvi a while until I really nail it down. Then all of the cool stuff that
vim offers, or neovim, will seem like icing on the cake that is vi.

Thanks to Ken Thompson for writing a work of art that serves as the true
core of this editor, to Bill Joy for his great work in extending it,
again to Bill Joy for bringing vi to life, and to Mary Ann for the
macros and making it accessible to the rest of us, and others who
contributed. It's 2024 and I still can't find a better terminal editor
than vi... as it existed in the late '80s or as it exists today as
nvi/vim/neovim. Amazing piece of software.

Off to figure out tags!! Arg, seems like it oughtta be really useful in
my work with source code, why can't I figure it out?! Sheesh.

Will