The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Marc Rochkind <mrochkind@gmail.com>
To: Will Senn <will.senn@gmail.com>
Cc: TUHS <tuhs@tuhs.org>
Subject: [TUHS] Re: diving into vi (nvi) - some observations from a slow learner
Date: Fri, 7 Jun 2024 11:29:29 -0600	[thread overview]
Message-ID: <CAOkr1zVN26F6UBaSqVb+tQN0VHa+mgmG0Wk07Omz59LeG5Uucw@mail.gmail.com> (raw)
In-Reply-To: <a79c56d0-c198-4496-a153-0be900519137@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6610 bytes --]

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
>


-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

[-- Attachment #2: Type: text/html, Size: 7527 bytes --]

  parent reply	other threads:[~2024-06-07 17:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07 14:44 [TUHS] " Will Senn
2024-06-07 15:41 ` [TUHS] " Ralph Corderoy
2024-06-07 16:20   ` Will Senn
2024-06-07 16:58     ` Andy Kosela
2024-06-07 17:29 ` Marc Rochkind [this message]
2024-06-08  4:44   ` Dave Horsfall
2024-06-08  4:50     ` Warner Losh
2024-06-08  6:22       ` Rob Pike
2024-06-07 22:12 ` Scot Jenkins via TUHS
2024-06-08 10:19   ` [TUHS] POSIX ed(1)'s exit status. (Was: diving into vi...) Ralph Corderoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOkr1zVN26F6UBaSqVb+tQN0VHa+mgmG0Wk07Omz59LeG5Uucw@mail.gmail.com \
    --to=mrochkind@gmail.com \
    --cc=tuhs@tuhs.org \
    --cc=will.senn@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).