[TUHS] diving into vi (nvi) - some observations from a slow learner

[TUHS] diving into vi (nvi) - some observations from a slow learner

[Will Senn]

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

[TUHS] Re: diving into vi (nvi) - some observations from a slow learner

[Ralph Corderoy]

Hi Will,

> But, I think I'll stick with nvi a while until I really nail it down.

Something I used to do was to look at each key on the keyboard and think
what it would do, e.g. d, D, and ^D.  Most do at least one thing.

> Leftward motions - [[, {, (, 0, ^|_, B, b, h|^H
> Rightward Movement - l|SP, e, E, w, W, $, ), }, ]]

You're missing these handy six: f F t T ; ,

> Upward motions - 1G, ^B, H, ^U, -, k | ^P
> Downward motions - G, ^F, L, ^D, ^M | +, j | ^J | ^N

There's also keeping the cursor on the same line but moving the window
over the text: z ^E ^Y

> Off to figure out tags

Understand the format of the tags file first; built by ctags(1).
^] on a word looks it up and goes there.
Where you were is pushed on to the ‘tagstack’.
When you wish to exit that rabbit hole, ^T pops the top of the stack and
goes there which returns you to where you pressed ^].

    $ func='foo bar xyzzy'
    $ printf "%s: $func"'\n' $func >src
    $ cat src
    foo: foo bar xyzzy
    bar: foo bar xyzzy
    xyzzy: foo bar xyzzy
    $ grep -n '[^:]*' src | awk -F: '{print $2 "\tsrc\t" $1}' >tags
    $ sed -n l tags
    foo\tsrc\t1$
    bar\tsrc\t2$
    xyzzy\tsrc\t3$
    $

vi src, move to a word, ^] and it will move you to the ‘definition’
line.  Imagine each line is a function definition with calls to other
functions.  You're wandering down and up a ‘call tree’, following
possible execution paths.

-- 
Cheers, Ralph.

[TUHS] Re: diving into vi (nvi) - some observations from a slow learner

[Will Senn]

Thanks for the tips, Ralph. I definitely learned the 6, but put 'em on a 
card with searching. Here's my motion card, including the scrolling 
commands, mark movement and a couple odd balls, to see how my mind works 
:) :

https://decuser.github.io/assets/img/vi/motions-notecard.jpg

On another note, I was reminded in an offline discussion that QED was 
the predecessor to ed - my history of tech always seems to glitch at the 
genesis of Unix. Of course the Unix pioneers didn't say "Let there be 
Unix and so mote it be" even though it may seems so to some of us. A lot 
of intellectual blood, sweat, and tears went into what came before and 
Ken Thompson definitely stood on the shoulders of Lampson, Deutsch, 
Kleene and others to create his masterpiece.

Ritchie's partial history of QED
https://www.bell-labs.com/usr/dmr/www/qed.html

Deutsch & Lampson's work
https://dl.acm.org/doi/pdf/10.1145/363848.363863

Thompson's innovation
https://dl.acm.org/doi/pdf/10.1145/363347.363387

Kleene's indirect contribution (Automata<->Regular Expression)
https://www.logicmatters.net/tyl/booknotes/kleene-metamath/

Later,

Will

On 6/7/24 10:41 AM, Ralph Corderoy wrote:
> Hi Will,
>
>> But, I think I'll stick with nvi a while until I really nail it down.
> Something I used to do was to look at each key on the keyboard and think
> what it would do, e.g. d, D, and ^D.  Most do at least one thing.
>
>> Leftward motions - [[, {, (, 0, ^|_, B, b, h|^H
>> Rightward Movement - l|SP, e, E, w, W, $, ), }, ]]
> You're missing these handy six: f F t T ; ,
>
>> Upward motions - 1G, ^B, H, ^U, -, k | ^P
>> Downward motions - G, ^F, L, ^D, ^M | +, j | ^J | ^N
> There's also keeping the cursor on the same line but moving the window
> over the text: z ^E ^Y
>
>> Off to figure out tags
> Understand the format of the tags file first; built by ctags(1).
> ^] on a word looks it up and goes there.
> Where you were is pushed on to the ‘tagstack’.
> When you wish to exit that rabbit hole, ^T pops the top of the stack and
> goes there which returns you to where you pressed ^].
>
>      $ func='foo bar xyzzy'
>      $ printf "%s: $func"'\n' $func >src
>      $ cat src
>      foo: foo bar xyzzy
>      bar: foo bar xyzzy
>      xyzzy: foo bar xyzzy
>      $ grep -n '[^:]*' src | awk -F: '{print $2 "\tsrc\t" $1}' >tags
>      $ sed -n l tags
>      foo\tsrc\t1$
>      bar\tsrc\t2$
>      xyzzy\tsrc\t3$
>      $
>
> vi src, move to a word, ^] and it will move you to the ‘definition’
> line.  Imagine each line is a function definition with calls to other
> functions.  You're wandering down and up a ‘call tree’, following
> possible execution paths.
>

[TUHS] Re: diving into vi (nvi) - some observations from a slow learner

[Andy Kosela]

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

On Friday, June 7, 2024, Will Senn <will.senn@gmail.com> wrote:

> Thanks for the tips, Ralph. I definitely learned the 6, but put 'em on a
> card with searching. Here's my motion card, including the scrolling
> commands, mark movement and a couple odd balls, to see how my mind works :)
> :
>
> https://decuser.github.io/assets/img/vi/motions-notecard.jpg
>
>
The best thing about vi/nvi/vim is that you do not need to know all the
arcane commands for it to be usable. You can get along quite happily using
just a small subset of them. The beauty of vi lies in the interface
minimalism and ubiquity.

It is still my favorite editor after all these years and still using it on
Linux/*BSD/MS-DOS/AmigaOS.

--Andy

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

[TUHS] Re: diving into vi (nvi) - some observations from a slow learner

[Marc Rochkind]

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

[TUHS] Re: diving into vi (nvi) - some observations from a slow learner

[Scot Jenkins via TUHS]

Will Senn <will.senn@gmail.com> wrote:

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

vim has a *lot* of knobs to twist, all of which must be in just the
right position for it to be comfortably usable, in my opinion.  I got
annoyed with many of the default features, like the auto indenting and 
getting stuck in comment mode.  Start a comment in vim and try to get
out of that mode.  I found I spent too much time trying to figure out 
how to turn off these things so I generally went back to straight vi 
as my daily editor.  I use ed(1) a lot too for quick edits.  vim is 
great for the syntax highlighting when coding or editing HTML though.  
It makes it easy to spot errors.



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

I think the best way to learn vi/vim features is from watching someone
else use it.  You pick up a lot of useful tricks.  Mike Shah has many 
great videos; here are a couple vi/vim related ones.  

1. Why I'm Still using Vim in 2024 - A Brief Introduction and Demo
https://www.youtube.com/watch?v=e4E6nQpd7Xs

This is a good quick into to using vi/vim.


2. [Dlang Episode 31] D Language - ctags with dscanner for VIM
   (and ctags with phobos demonstration)
https://www.youtube.com/watch?v=vMF7NxF_HFY

While he uses the D programming language for this video, it is a
great demo of how to use ctags.  The principle is the same for other
programming languages, ctags supports many, run:
"ctags --list-languages" to view the full list.

scot

[TUHS] Re: diving into vi (nvi) - some observations from a slow learner

[Dave Horsfall]

On Fri, 7 Jun 2024, Marc Rochkind wrote:

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

As the saying goes, EMACS is for people who can't remember what mode 
they're in :-)

-- Dave

[TUHS] Re: diving into vi (nvi) - some observations from a slow learner

[Warner Losh]

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

On Fri, Jun 7, 2024, 10:45 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Fri, 7 Jun 2024, Marc Rochkind wrote:
>
> > Other editors didn't work that way. I think emacs was non-modal,
> > although I never used it. (Could be wrong.)
>
> As the saying goes, EMACS is for people who can't remember what mode
> they're in :-)
>

One less thing helps us focus on ond more thing that actually matters  :)

Warner

-- Dave
>

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

[TUHS] Re: diving into vi (nvi) - some observations from a slow learner

[Rob Pike]

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

https://9p.io/magic/man2html/1/vi is the manual for Plan 9's vi.

-rob

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

[TUHS] POSIX ed(1)'s exit status. (Was: diving into vi...)

[Ralph Corderoy]

Hi,

Will Senn wrote:
> I use ed(1) a lot too for quick edits.

Me too.  I've heard others who have told crontab(1) or their mail
program to use ed have been bitten by the exit status varying between
0 and 1.  ed(1p) explains:

    EXIT STATUS
        The following exit values shall be returned:

         0    Successful completion without any file or command errors.
        >0    An error occurred.

This behaviour is surprising.  Here's GNU ed:

    $ ed /tmp/foo
        /tmp/foo: No such file or directory
        a
        foo
        .
        wq
        4
    $ echo $?
        0
    $ ed /tmp/foo
        4
        /bar
        ?
        $a
        bar
        .
        wq
        8
    $ echo $?
        1
    $

I assume POSIX made it the default behaviour to be useful when ed isn't
talking to mankind.  Perhaps they think that's the default these days.
GNU ed added -l:

       -l, --loose-exit-status
              exit with 0 status even if a command fails

>From https://man.netbsd.org/ed.1, I don't think BSD ed has a similar
option.  Probably, because it doesn't need it as my quick skim of
http://bxr.su/NetBSD/bin/ed/main.c#220 suggests it will exit(0) even if
an earlier search found nothing.  There is a list of BSD's differences
to POSIX, e.g. ‘z’ for scrolling, amidst the source,
http://bxr.su/NetBSD/bin/ed/POSIX, but it doesn't mention the exit
status.

-- 
Cheers, Ralph.