* [TUHS] diving into vi (nvi) - some observations from a slow learner @ 2024-06-07 14:44 Will Senn 2024-06-07 15:41 ` [TUHS] " Ralph Corderoy ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Will Senn @ 2024-06-07 14:44 UTC (permalink / raw) To: TUHS 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: diving into vi (nvi) - some observations from a slow learner 2024-06-07 14:44 [TUHS] diving into vi (nvi) - some observations from a slow learner Will Senn @ 2024-06-07 15:41 ` Ralph Corderoy 2024-06-07 16:20 ` Will Senn 2024-06-07 17:29 ` Marc Rochkind 2024-06-07 22:12 ` Scot Jenkins via TUHS 2 siblings, 1 reply; 10+ messages in thread From: Ralph Corderoy @ 2024-06-07 15:41 UTC (permalink / raw) To: TUHS 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: diving into vi (nvi) - some observations from a slow learner 2024-06-07 15:41 ` [TUHS] " Ralph Corderoy @ 2024-06-07 16:20 ` Will Senn 2024-06-07 16:58 ` Andy Kosela 0 siblings, 1 reply; 10+ messages in thread From: Will Senn @ 2024-06-07 16:20 UTC (permalink / raw) To: Ralph Corderoy, TUHS 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. > ^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: diving into vi (nvi) - some observations from a slow learner 2024-06-07 16:20 ` Will Senn @ 2024-06-07 16:58 ` Andy Kosela 0 siblings, 0 replies; 10+ messages in thread From: Andy Kosela @ 2024-06-07 16:58 UTC (permalink / raw) To: Will Senn; +Cc: TUHS [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: diving into vi (nvi) - some observations from a slow learner 2024-06-07 14:44 [TUHS] diving into vi (nvi) - some observations from a slow learner Will Senn 2024-06-07 15:41 ` [TUHS] " Ralph Corderoy @ 2024-06-07 17:29 ` Marc Rochkind 2024-06-08 4:44 ` Dave Horsfall 2024-06-07 22:12 ` Scot Jenkins via TUHS 2 siblings, 1 reply; 10+ messages in thread From: Marc Rochkind @ 2024-06-07 17:29 UTC (permalink / raw) To: Will Senn; +Cc: TUHS [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: diving into vi (nvi) - some observations from a slow learner 2024-06-07 17:29 ` Marc Rochkind @ 2024-06-08 4:44 ` Dave Horsfall 2024-06-08 4:50 ` Warner Losh 0 siblings, 1 reply; 10+ messages in thread From: Dave Horsfall @ 2024-06-08 4:44 UTC (permalink / raw) To: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: diving into vi (nvi) - some observations from a slow learner 2024-06-08 4:44 ` Dave Horsfall @ 2024-06-08 4:50 ` Warner Losh 2024-06-08 6:22 ` Rob Pike 0 siblings, 1 reply; 10+ messages in thread From: Warner Losh @ 2024-06-08 4:50 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: diving into vi (nvi) - some observations from a slow learner 2024-06-08 4:50 ` Warner Losh @ 2024-06-08 6:22 ` Rob Pike 0 siblings, 0 replies; 10+ messages in thread From: Rob Pike @ 2024-06-08 6:22 UTC (permalink / raw) To: Warner Losh; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] Re: diving into vi (nvi) - some observations from a slow learner 2024-06-07 14:44 [TUHS] diving into vi (nvi) - some observations from a slow learner Will Senn 2024-06-07 15:41 ` [TUHS] " Ralph Corderoy 2024-06-07 17:29 ` Marc Rochkind @ 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 2 siblings, 1 reply; 10+ messages in thread From: Scot Jenkins via TUHS @ 2024-06-07 22:12 UTC (permalink / raw) To: will.senn, 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [TUHS] POSIX ed(1)'s exit status. (Was: diving into vi...) 2024-06-07 22:12 ` Scot Jenkins via TUHS @ 2024-06-08 10:19 ` Ralph Corderoy 0 siblings, 0 replies; 10+ messages in thread From: Ralph Corderoy @ 2024-06-08 10:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-06-08 10:19 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-06-07 14:44 [TUHS] diving into vi (nvi) - some observations from a slow learner 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 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
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).