[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

Last post on this topic because life is too short. Will, you can do whatever you want. If you worked for me, this would be a much shorter conversation and you'd be using vim. Modern tools are more complicated because they do more stuff. Taking your position to the extreme would have you using a pipeline piped to ed, would it not? vi is a BSDism, so it isn't "pure", nvi is a rewrite of Joys vi (why? Anyone?) I get the desire to have simple tools, I'm that way too, but switching from vi, nvi to vim was seamless. I've never looked at their documentation other than :help to find how to manipulate their windows. Everything else just worked. Have fun with nvi. On Fri, Jul 18, 2025 at 01:28:54PM -0500, Will Senn wrote: > Ha Larry. I'm not hidebound, but I do like to understand the software I use > and I'm more of the if it ain't broke persuasion. The vim manual is maybe > 5000 pages now (https://nathangrigg.com/vimhelp/vimhelp.pdf) only about > 100x the nvi manual.... but yeah, different strokes for different folks. > > Seems like we're in the weeds though, almost COFF worthy. > > I do wonder about vi though and when it became prevalent. In v6, it's > supposedly possible to get it working, but I've never seen it in virtual > environs (oh how I've tried). In v7, it's more possible, but again, I've not > seen it really working in SIMH (tried that too). BSD 2.11 gets the nod, but > was it delivered as part of any system prior to 2.11 or was 2.11 really the > first post v7 unix with vi with wider adoption? > > Later, > > Will > > > > On 7/18/25 07:52, Larry McVoy wrote: >> That's fine, if it works for you it works for you. For me, vim is >> compat enough (and it has a way to make it more compat if you care >> I believe) and has some functionality that makes me shake my head >> at the nvi people. >> >> To me, nvi is sort of like v7. Yeah, it's like the original Unix >> but would you want to live there just because it is "pure"? No >> networking, no top, it's just a basic Unix. Cool because of how >> small it is but pretty painful to live there. >> >> On Fri, Jul 18, 2025 at 07:24:46AM -0500, Will Senn wrote: >>> nvi does everything i need it to, it's help fits on a couple of screens, and >>> it's easy to remember it all. maybe if I hit a wall with it, I'll reinstall >>> vim, but for the screen stuff, don't need it. I don't live in my editor, or >>> even the command line, I just use it when it's convenient - which admittedly >>> is a lot of the time. But, it's the terminal that's most useful, not vi. So, >>> if I want more screen, I just open a terminal window. My monitor has room >>> for a dozen or so :) not including guake, workspaces, etc... in the modern >>> era, of course! >>> >>> Will >>> >>> On 7/18/25 05:09, Larry McVoy wrote: >>>> On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah via TUHS wrote: >>>>> On Jul 17, 2025, at 7:52???PM, segaloco via TUHS <tuhs(a)tuhs.org> wrote: >>>>>>> If you just do ":E" it will put both windows on the current file, >>>>>>> exactly the same as vim. But both do it wrong (IMHO) as the second >>>>>>> window starts at the same place (e.g top of the file). In the Rand >>>>>>> Editor if the split is at line N, the bottom window shows lines N+1. >>>>>>> Exact same behavior for vertical split (the left and right side >>>>>>> windows show the same portions as before). >>>>>>> >>>>>>>> On Jul 17, 2025, at 6:09???PM, Larry McVoy lm(a)mcvoy.com wrote: >>>>>>>> >>>>>>>> Not really the same. :sp splits your window in half and puts you in >>>>>>>> two different windows on the same file. Each window, in vim, is full >>>>>>>> on vi, you can do :e fillename and now that window is on that file. >>>>>> Not historic but as of present I shunt windowing off to GNU screen and just have separate nvi sessions in each. This may speak to ignorance on my part regarding advantages of opening multiple files in the same session in any given vi. I keep vim around for when I need the value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your window configuration tightly coupled, but I also frequently have vi in one pane and am using the others for od output and build/test cycle for disassembly projects. >>>>> Going via screen(1) can be more painful. If you want to copy some lines >>>> >from one file to another, you have to either create a temp file or >>>>> use the window systems's cut/paste buffer/clipboard. The latter can >>>>> actually works worse (if you have autoindent turned on for example). >>>>> Also the modal nature of vi/vim can wreak havoc (copied text can be >>>>> mistakenly interpreted as commands). >>>>> >>>>> In vi you can yank lines in file1, paste in file2. And can share >>>>> options, tags etc. In the rand editor you can scroll two windows in >>>>> unison (handy if one shows column headings and the other some rows). >>>>> See acme for an example of a well designed multi window editor. >>>> I was going to respond to the screen stuff but Bakul beat me to it. >>>> In vim, you just have a split view of the same file. Changes in >>>> either window will show up in the other window. For example >>>> >>>> vim foo.c # foo.c exists and has a 100 lines >>>> :sp >>>> >>>> now you have both windows looking at the same file >>>> >>>> start changing something and it is done in both windows. >>>> >>>> Screen is nowhere near that and using it to claim that nvi is fine >>>> is missing the point by a country mile. >>>> >>>> And I don't understand the dislike of vim. Sure, it's got a pile >>>> of stuff that old time Unix people would dislike "cat came back >>> >from BSD wagging it's tail" (or something that Rob said) but you >>>> don't have to use any of that. For me, vim is a finger compat >>>> vi clone that has some really really useful extensions, I use >>>> :split >>>> all the time. Saying you prefer nvi in the face of that is >>>> something that makes no sense to me. I've used nvi, I get that >>>> it is compat with Joys vi, but so what? vim is more useful and >>>> it is also compat. >>>> >>>> Time marches on, perhaps march with it? >>>> >>>> --lm