* [TUHS] screen editors
@ 2020-01-07 2:31 Doug McIlroy
2020-01-07 2:37 ` Brantley Coile
` (5 more replies)
0 siblings, 6 replies; 118+ messages in thread
From: Doug McIlroy @ 2020-01-07 2:31 UTC (permalink / raw)
To: tuhs
> but…damn, even ex/vi 3.x is huge
It was so excesssive right from the start that I refused to use it.
Sam was the first screen editor that I deemed worthwhile, and I
still use it today.
Doug
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 2:31 [TUHS] screen editors Doug McIlroy @ 2020-01-07 2:37 ` Brantley Coile 2020-01-07 2:38 ` Larry McVoy ` (4 subsequent siblings) 5 siblings, 0 replies; 118+ messages in thread From: Brantley Coile @ 2020-01-07 2:37 UTC (permalink / raw) To: Doug McIlroy; +Cc: tuhs Well said. I do as well. > On Jan 6, 2020, at 9:31 PM, Doug McIlroy <doug@cs.dartmouth.edu> wrote: > >> but…damn, even ex/vi 3.x is huge > > It was so excesssive right from the start that I refused to use it. > Sam was the first screen editor that I deemed worthwhile, and I > still use it today. > > Doug ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 2:31 [TUHS] screen editors Doug McIlroy 2020-01-07 2:37 ` Brantley Coile @ 2020-01-07 2:38 ` Larry McVoy 2020-01-07 16:30 ` arnold 2020-01-07 6:19 ` Dave Horsfall ` (3 subsequent siblings) 5 siblings, 1 reply; 118+ messages in thread From: Larry McVoy @ 2020-01-07 2:38 UTC (permalink / raw) To: Doug McIlroy; +Cc: tuhs On Mon, Jan 06, 2020 at 09:31:44PM -0500, Doug McIlroy wrote: > > but???damn, even ex/vi 3.x is huge > > It was so excesssive right from the start that I refused to use it. > Sam was the first screen editor that I deemed worthwhile, and I > still use it today. I grew up on 4MB Suns. Emacs was "8 megs and constantly swapping". I thought vi was fine though I did do a lot with xvi (I think that was what it was called) and I hacked it to use mmap to look at the file. I had to do something about strings to make that work, don't remember, but it worked and I could vi 4MB log files and search them pretty fast. I'm a vi guy to this day. Love it. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 2:38 ` Larry McVoy @ 2020-01-07 16:30 ` arnold 2020-01-07 16:38 ` Richard Salz ` (4 more replies) 0 siblings, 5 replies; 118+ messages in thread From: arnold @ 2020-01-07 16:30 UTC (permalink / raw) To: lm, doug; +Cc: tuhs Larry McVoy <lm@mcvoy.com> wrote: > I'm a vi guy to this day. Love it. In the summer of '82 I did some contract programming at Southern Bell on a PDP-11 running USG Unix 4.0. It had a screen editor called 'se' that I only ever saw there, written somewhere in the Bell System and squeezed to run on an -11. Anyone know anything about it? Unrelated, Georgia Tech had the 'se' screen editor as part of the Software Tools Subsystem, based on the 'ed' in the Software Tools book. This was later ported to Unix. I modified that code to use curses/termlib and posted it to USENET. It's been updated and is available from https://github.com/se-editor/se and http://se-editor.org is the home page. (Thomas Cort IIRC did that work.) What's funny is that in doing the work to get 'se' running on Georgia Tech's Vax, I had to learn vi. By the time I was done, vi had become my main editor and had burned itself into my finger's ROMs. Arnold ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 16:30 ` arnold @ 2020-01-07 16:38 ` Richard Salz 2020-01-07 18:32 ` Dan Cross ` (3 subsequent siblings) 4 siblings, 0 replies; 118+ messages in thread From: Richard Salz @ 2020-01-07 16:38 UTC (permalink / raw) To: arnold; +Cc: The Eunuchs Hysterical Society, Doug McIlroy [-- Attachment #1: Type: text/plain, Size: 176 bytes --] Any fans of the Rand Editor? https://github.com/blakemcbride/Rand-E-Editor And do folks here know of the TextEditors wiki at http://texteditors.org/cgi-bin/wiki.pl?HomePage ? [-- Attachment #2: Type: text/html, Size: 380 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 16:30 ` arnold 2020-01-07 16:38 ` Richard Salz @ 2020-01-07 18:32 ` Dan Cross 2020-01-07 19:14 ` Thomas Paulsen ` (2 subsequent siblings) 4 siblings, 0 replies; 118+ messages in thread From: Dan Cross @ 2020-01-07 18:32 UTC (permalink / raw) To: Aharon Robbins; +Cc: The Eunuchs Hysterical Society, Doug McIlroy [-- Attachment #1: Type: text/plain, Size: 3159 bytes --] On Tue, Jan 7, 2020 at 11:31 AM <arnold@skeeve.com> wrote: > Larry McVoy <lm@mcvoy.com> wrote: > > > I'm a vi guy to this day. Love it. > > In the summer of '82 I did some contract programming at Southern Bell > on a PDP-11 running USG Unix 4.0. It had a screen editor called 'se' > that I only ever saw there, written somewhere in the Bell System and > squeezed to run on an -11. Anyone know anything about it? > > Unrelated, Georgia Tech had the 'se' screen editor as part of the > Software Tools Subsystem, based on the 'ed' in the Software Tools book. > This was later ported to Unix. I modified that code to use curses/termlib > and posted it to USENET. It's been updated and is available from > https://github.com/se-editor/se and http://se-editor.org is the home > page. (Thomas Cort IIRC did that work.) > > What's funny is that in doing the work to get 'se' running on Georgia > Tech's Vax, I had to learn vi. By the time I was done, vi had become > my main editor and had burned itself into my finger's ROMs. > Ah, this reminds me of something. I assume you've read, "A Software Tools Sampler"? A few months ago, I started looking into screen update algorithms for a (frivolous) retro-computing time sink, er, I mean project. Naturally, Gosling's redisplay algorithm figured prominently, as it's famous and well-known. I looked at the Unix emacs code and it's not that hard to puzzle through, actually, despite the reputation and the (in)famous skull and crossbones comment. However, Gosling's code assumes that update commands all have uniform cost (cost here being proportional to the command's length) which, on real terminals, just isn't true. Meyers and Miller came up with several algorithms that take into account editing command cost, and produce potentially far-better solutions than Gosling's code, though limited by the inability at the time to quickly build suffix trees (this was about a decade before Ukkonen's algorithm); it's interesting that none of these algorithms take into account text attributes, which on most serial terminals are modal. Anyway, at least one of these algorithms was implemented in a modified version of `se`, as described in "A Software Tools Sampler." I guess Webb thought that was easier to work with than an existing editor? Perhaps these "se"s share a lineage? What's interesting to me is that redisplay algorithms were clearly an area of active research at one time, but interest seemed to dry up almost over night. One must presume that this evaporation of research activity had to do with the en mass migration to graphical workstations where the problems are different, and possibly with curses being "good enough" in e.g. an xterm. However, one can see some of the fruits of Miller's research in his later work in genomics. - Dan C. A few random references: Gosling, James, "A Redisplay Algorithm." https://dl.acm.org/doi/10.1145/872730.806463 Meyers, Eugene and Webb Miller, "A Simple Row Replacement Algorithm." https://dl.acm.org/doi/10.5555/52187.52188 Meyers, Eugene and Webb Miller, "Row Replacement Algorithm for Screen Editors." https://dl.acm.org/doi/10.1145/59287.59290 [-- Attachment #2: Type: text/html, Size: 4333 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 16:30 ` arnold 2020-01-07 16:38 ` Richard Salz 2020-01-07 18:32 ` Dan Cross @ 2020-01-07 19:14 ` Thomas Paulsen 2020-01-09 5:01 ` Grant Taylor via TUHS 2020-01-08 0:10 ` Jon Steinhart 2020-01-08 18:30 ` Mary Ann Horton 4 siblings, 1 reply; 118+ messages in thread From: Thomas Paulsen @ 2020-01-07 19:14 UTC (permalink / raw) To: arnold; +Cc: tuhs, doug >What's funny is that in doing the work to get 'se' running on Georgia >Tech's Vax, I had to learn vi. By the time I was done, vi had become >my main editor and had burned itself into my finger's ROMs. I do ed/se occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all bigger projects, beside liteide for golang. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 19:14 ` Thomas Paulsen @ 2020-01-09 5:01 ` Grant Taylor via TUHS 2020-01-10 8:16 ` ricercar 0 siblings, 1 reply; 118+ messages in thread From: Grant Taylor via TUHS @ 2020-01-09 5:01 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 213 bytes --] On 1/7/20 12:14 PM, Thomas Paulsen wrote: > I do ed/se occasionally for simple tasks Was that supposed to be "sed"? Or is "se" something that I'm not familiar with? -- Grant. . . . unix || die [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4013 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 5:01 ` Grant Taylor via TUHS @ 2020-01-10 8:16 ` ricercar 0 siblings, 0 replies; 118+ messages in thread From: ricercar @ 2020-01-10 8:16 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 314 bytes --] On 1/9/20 5:01 AM, Grant Taylor via TUHS wrote: > On 1/7/20 12:14 PM, Thomas Paulsen wrote: >> I do ed/se occasionally for simple tasks > Was that supposed to be "sed"? Or is "se" something that I'm not > familiar with? > I think he is referring to http://se-editor.org/, mentioned earlier in the thread. vks [-- Attachment #2: Type: text/html, Size: 851 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 16:30 ` arnold ` (2 preceding siblings ...) 2020-01-07 19:14 ` Thomas Paulsen @ 2020-01-08 0:10 ` Jon Steinhart 2020-01-17 22:06 ` Dave Horsfall 2020-01-08 18:30 ` Mary Ann Horton 4 siblings, 1 reply; 118+ messages in thread From: Jon Steinhart @ 2020-01-08 0:10 UTC (permalink / raw) To: tuhs arnold@skeeve.com writes: > Larry McVoy <lm@mcvoy.com> wrote: > > > I'm a vi guy to this day. Love it. I'm a vi guy these days. My first screen editor was something called DTE for Display Terminal Editor written by Dick Hause that ran on the Glance G terminals hooked our Honeywell 516 running 516-TSS. I have some vague recollection of at least one of these terminals ending up in the attic in the UNIX room, but I don't think that the editor was ever ported. It was painful to have to use ed or the 516-TSS equivalent when a terminal wasn't available. Vi was an easy transition because the ed commands could be used until the fancier stuff was learned. Also because that great vi trainer program rogue existed :-) Jon ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 0:10 ` Jon Steinhart @ 2020-01-17 22:06 ` Dave Horsfall 0 siblings, 0 replies; 118+ messages in thread From: Dave Horsfall @ 2020-01-17 22:06 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Tue, 7 Jan 2020, Jon Steinhart wrote: > Also because that great vi trainer program rogue existed :-) The story is told of some professor having to learn VI, because EMACS was not available. After a few minutes, he said "Hmmm... It's just like Rogue". FWIW, I once discovered a bug in the Curses library following an upgrade on the Mac: Rogue had stopped working :-) -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 16:30 ` arnold ` (3 preceding siblings ...) 2020-01-08 0:10 ` Jon Steinhart @ 2020-01-08 18:30 ` Mary Ann Horton 2020-01-08 21:41 ` Thomas Paulsen 2020-01-09 8:30 ` arnold 4 siblings, 2 replies; 118+ messages in thread From: Mary Ann Horton @ 2020-01-08 18:30 UTC (permalink / raw) To: tuhs It's interesting how much of this has been lost to history. Curses, in particular, is sketchily documented, and se is unknown. Here's how I remember it. Bill Joy made major enhancements to previously enhanced versions of ed, creating vi. In 1979, he bumped up against the 64K boundary on the PDP-11, and handed it off to me. I made some more smaller enhancements. vi was huge by the standards of the day, especially compared to ed. There were ifdefs to take out several features, such as support for upper case only terminals, to make it fit on the PDP-11. I had to split it into version 2 (16 bit) and 3 (32 bit) to be able to enhance it and still support 2BSD on the PDP-11. Ken Arnold took the screen updating code from vi (just the "full screen update", not the parts that did insert/delete line/char) and turned it into the curses library. Rogue was the primary user of curses. Once I graduated from Berkeley went to Bell Labs, I took vi, termcap, and curses with me. I replaced termcap, which was too slow to start up (it was quadratic on the size of the entry, which was awful on the hardware of the day) with terminfo, a binary version that was faster. It included tools like tic and infocmp to translate back and forth to text and termcap. I also rewrote curses with a new algorithm that fully utilized insert/delete line/char. I had a paper to publish on the subject, but I lost it and never did publish it. I gave a talk at Usenix Boston in 1982 about the new curses and terminfo. But I couldn't release the code, because it was considered proprietary. Pavel Curtis offered to clone it, and I coached him on the algorithm and specs, and he released a good clone pcurses. Eventually that became ncurses. Nearly everyone at Bell Labs (outside area 11) was using either vi or emacs, but System III just had ed. There was a big push to add vi or emacs to UNIX 3.0 (System III), but USG instead chose to write se, the "screen editor" and put it in UNIX 4.0. Nobody would use it, so UNIX 5.0 (System V) relented and included vi. Mary Ann On 1/7/20 8:30 AM, arnold@skeeve.com wrote: > Larry McVoy <lm@mcvoy.com> wrote: > >> I'm a vi guy to this day. Love it. > In the summer of '82 I did some contract programming at Southern Bell > on a PDP-11 running USG Unix 4.0. It had a screen editor called 'se' > that I only ever saw there, written somewhere in the Bell System and > squeezed to run on an -11. Anyone know anything about it? > > Unrelated, Georgia Tech had the 'se' screen editor as part of the > Software Tools Subsystem, based on the 'ed' in the Software Tools book. > This was later ported to Unix. I modified that code to use curses/termlib > and posted it to USENET. It's been updated and is available from > https://github.com/se-editor/se and http://se-editor.org is the home > page. (Thomas Cort IIRC did that work.) > > What's funny is that in doing the work to get 'se' running on Georgia > Tech's Vax, I had to learn vi. By the time I was done, vi had become > my main editor and had burned itself into my finger's ROMs. > > Arnold ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 18:30 ` Mary Ann Horton @ 2020-01-08 21:41 ` Thomas Paulsen 2020-01-09 8:30 ` arnold 1 sibling, 0 replies; 118+ messages in thread From: Thomas Paulsen @ 2020-01-08 21:41 UTC (permalink / raw) To: Mary Ann Horton; +Cc: tuhs >It's interesting how much of this has been lost to history. Curses, in thanks for the deep insider view. I heard that Bill's ex/vi sources were incomprehensible 'read never' code. Hence it makes no wonder that everybody failed adding real support for cursor keys. beyond automatically switching from insert to visual mode on hitting any cursor key! ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 18:30 ` Mary Ann Horton 2020-01-08 21:41 ` Thomas Paulsen @ 2020-01-09 8:30 ` arnold 1 sibling, 0 replies; 118+ messages in thread From: arnold @ 2020-01-09 8:30 UTC (permalink / raw) To: tuhs, mah Mary Ann Horton <mah@mhorton.net> wrote: > Nearly everyone at Bell Labs (outside area 11) was using either vi or > emacs, but System III just had ed. There was a big push to add vi or > emacs to UNIX 3.0 (System III), but USG instead chose to write se, the > "screen editor" and put it in UNIX 4.0. Nobody would use it, so UNIX 5.0 > (System V) relented and included vi. Thanks for confirming that se existed in Unix 4.0, as I remember it. I used it some; the only thing I remember about it was that the command line was at the top of the screen. I must have been disappointed with it, because I ended up doing most of my contract programming work in ed. :-) It'd be interesting to see the source for this 'se', but it's probably lost forever. Arnold ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 2:31 [TUHS] screen editors Doug McIlroy 2020-01-07 2:37 ` Brantley Coile 2020-01-07 2:38 ` Larry McVoy @ 2020-01-07 6:19 ` Dave Horsfall 2020-01-07 8:24 ` Thomas Paulsen 2020-01-08 15:29 ` Steve Mynott 2020-01-07 9:43 ` ullbeking ` (2 subsequent siblings) 5 siblings, 2 replies; 118+ messages in thread From: Dave Horsfall @ 2020-01-07 6:19 UTC (permalink / raw) To: The Eunuchs Hysterical Society I don't recall the exact details, but there was once an editor called "em" (Editor for Mortals). I remember thinking: what sort of an idiot would call it that, with the "e" and "r" keys adjacent to each other? I wonder how many files were lost that way... -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 6:19 ` Dave Horsfall @ 2020-01-07 8:24 ` Thomas Paulsen 2020-01-07 20:44 ` Dave Horsfall 2020-01-08 15:29 ` Steve Mynott 1 sibling, 1 reply; 118+ messages in thread From: Thomas Paulsen @ 2020-01-07 8:24 UTC (permalink / raw) To: Dave Horsfall; +Cc: tuhs >I don't recall the exact details, but there was once an editor called "em" >(Editor for Mortals). I remember thinking: what sort of an idiot would >call it that, with the "e" and "r" keys adjacent to each >other? I wonder how many files were lost that way... you can download, build and use em making immediately clear that em was much easier to use than ed. Nevertheless em was only (another) step in between ed and vi. http://pgas.freeshell.org/C/em/ http://www.tuhs.org/Archive/Applications/Em_Editor/ http://www.coulouris.net/cs_history/em_story/emsource/ ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 8:24 ` Thomas Paulsen @ 2020-01-07 20:44 ` Dave Horsfall 0 siblings, 0 replies; 118+ messages in thread From: Dave Horsfall @ 2020-01-07 20:44 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Tue, 7 Jan 2020, Thomas Paulsen wrote: >> I don't recall the exact details, but there was once an editor called >> "em" (Editor for Mortals). I remember thinking: what sort of an idiot >> would call it that, with the "e" and "r" keys adjacent to each other? >> I wonder how many files were lost that way... > > you can download, build and use em making immediately clear that em was > much easier to use than ed. Nevertheless em was only (another) step in > between ed and vi. I'm sure you're right, but that wasn't the point that I was making... -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 6:19 ` Dave Horsfall 2020-01-07 8:24 ` Thomas Paulsen @ 2020-01-08 15:29 ` Steve Mynott 2020-01-08 23:31 ` Dave Horsfall 1 sibling, 1 reply; 118+ messages in thread From: Steve Mynott @ 2020-01-08 15:29 UTC (permalink / raw) To: TUHS main list On 07/01/2020, Dave Horsfall <dave@horsfall.org> wrote: > I don't recall the exact details, but there was once an editor called "em" > (Editor for Mortals). I remember thinking: what sort of an idiot would > call it that, with the "e" and "r" keys adjacent to each other? I wonder > how many files were lost that way... It was a line editor which resembled ex, came from QMC London and was used on some VAX BSD systems in UK Universities in the early '80s. The source is online. As for "rm" typos I'm sure many discovered netnews the same way! -- Steve Mynott <steve.mynott@gmail.com> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 15:29 ` Steve Mynott @ 2020-01-08 23:31 ` Dave Horsfall 0 siblings, 0 replies; 118+ messages in thread From: Dave Horsfall @ 2020-01-08 23:31 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Wed, 8 Jan 2020, Steve Mynott wrote: > As for "rm" typos I'm sure many discovered netnews the same way! OK, I'll admit that I was baffled until I took a closer look at my keyboard :-) -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 2:31 [TUHS] screen editors Doug McIlroy ` (2 preceding siblings ...) 2020-01-07 6:19 ` Dave Horsfall @ 2020-01-07 9:43 ` ullbeking 2020-01-07 14:53 ` Dan Cross 2020-01-07 19:35 ` Rodrigo G. López 2020-01-07 15:03 ` Clem Cole 2020-01-07 15:50 ` [TUHS] screen editors Thomas Paulsen 5 siblings, 2 replies; 118+ messages in thread From: ullbeking @ 2020-01-07 9:43 UTC (permalink / raw) To: tuhs 7 Jan 2020 02:32:11 Doug McIlroy : > Sam was the first screen editor that I deemed worthwhile, and I > still use it today. I would like to experiment with Sam and run it on various *nix operating systems. There seems to be many ports. Do I need to install some kind of Plan 9 emulation layer (in user space), which Sam builds and runs on? Obviously I'm referring to Russ Cox's libraries and user space tools. Is it necessary to have a p9 environment to gain the most advantage of a tool like Sam? Or, is it possible for it still to function well as a transplant in a new environment such as *nix? In that second case, what are the well ported versions of Sam that build and run directly on the target environment? Andrew ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 9:43 ` ullbeking @ 2020-01-07 14:53 ` Dan Cross 2020-01-07 19:35 ` Rodrigo G. López 1 sibling, 0 replies; 118+ messages in thread From: Dan Cross @ 2020-01-07 14:53 UTC (permalink / raw) To: ullbeking; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1318 bytes --] On Tue, Jan 7, 2020 at 4:50 AM <ullbeking@andrewnesbit.org> wrote: > 7 Jan 2020 02:32:11 Doug McIlroy : > > Sam was the first screen editor that I deemed worthwhile, and I > > still use it today. > > I would like to experiment with Sam and run it on various *nix operating > systems. There seems to be many ports. > > Do I need to install some kind of Plan 9 emulation layer (in user space), > which Sam builds and runs on? Obviously I'm referring to Russ Cox's > libraries and user space tools. > > Is it necessary to have a p9 environment to gain the most advantage of a > tool like Sam? Or, is it possible for it still to function well as a > transplant in a new environment such as *nix? > > In that second case, what are the well ported versions of Sam that build > and run directly on the target environment? > It is not necessary to have a plan 9 environment to take advantage of Sam, and there was once a port for Unix that worked outside of the usual Plan 9 world. Indeed, Sam got its start on Unix. However, I dare say that the best port to use is the one from plan9port: Sam continued to evolve on plan9, if only gaining incremental improvements after the early Unix years. By using the plan9port version, you'll pick up on those changes (though I can't really enumerate them anymore). - Dan C. [-- Attachment #2: Type: text/html, Size: 1715 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 9:43 ` ullbeking 2020-01-07 14:53 ` Dan Cross @ 2020-01-07 19:35 ` Rodrigo G. López 2020-01-08 5:13 ` Mark van Atten 1 sibling, 1 reply; 118+ messages in thread From: Rodrigo G. López @ 2020-01-07 19:35 UTC (permalink / raw) To: ullbeking; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 1349 bytes --] i like to use it natively as much as possible, especially the 9front edition with its usability (e.g. mouse chording) improvements. if that is not possible, i drawterm into some cpu or a local vm where i can get a little environment to work with whatever is at /mnt/term. it also has a powerful command language and structural regular expressions, and you can use your favorite unix tools on any piece of text you please. it has given me the best text editing and programming experience i've ever had. -rodri On Tue, Jan 7, 2020, 10:50 AM <ullbeking@andrewnesbit.org> wrote: > > 7 Jan 2020 02:32:11 Doug McIlroy : > > Sam was the first screen editor that I deemed worthwhile, and I > > still use it today. > > I would like to experiment with Sam and run it on various *nix operating > systems. There seems to be many ports. > > Do I need to install some kind of Plan 9 emulation layer (in user space), > which Sam builds and runs on? Obviously I'm referring to Russ Cox's > libraries and user space tools. > > Is it necessary to have a p9 environment to gain the most advantage of a > tool like Sam? Or, is it possible for it still to function well as a > transplant in a new environment such as *nix? > > In that second case, what are the well ported versions of Sam that build > and run directly on the target environment? > > Andrew > > > [-- Attachment #2: Type: text/html, Size: 1870 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 19:35 ` Rodrigo G. López @ 2020-01-08 5:13 ` Mark van Atten 0 siblings, 0 replies; 118+ messages in thread From: Mark van Atten @ 2020-01-08 5:13 UTC (permalink / raw) To: Rodrigo G. López; +Cc: tuhs On Tue, 7 Jan 2020 at 20:36, Rodrigo G. López <rodrigosloop@gmail.com> wrote: > > i like to use it natively as much as possible, especially the 9front edition with its usability (e.g. mouse chording) improvements. if that is not possible, i drawterm into some cpu or a local vm where i can get a little environment to work with whatever is at /mnt/term. In the opposite direction of your preference for a native environment: A port of 9front sam (with chording) to unix is available at https://bitbucket.org/iru/sam9f-unix/src/default/ I use it as a drop-in replacement for the plan9port version. > it has given me the best text editing and programming experience i've ever had. For most types of editing I have come to prefer it over acme. The one modification I should, perhaps, like to see is the possibility to scroll the window while selecting. Rob Pike has made some comments on the difficulty here; see the quotations and links in the discussion at https://github.com/deadpixi/sam/issues/85 (incidentally, on the github pages of another fairly recent port of sam.) A proposal for a (GSOC) project to improve sam scrolling: http://fqa.9front.org/appendixg.html Mark. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 2:31 [TUHS] screen editors Doug McIlroy ` (3 preceding siblings ...) 2020-01-07 9:43 ` ullbeking @ 2020-01-07 15:03 ` Clem Cole 2020-01-08 21:43 ` [TUHS] screen editors (FRED) Greg A. Woods 2020-01-07 15:50 ` [TUHS] screen editors Thomas Paulsen 5 siblings, 1 reply; 118+ messages in thread From: Clem Cole @ 2020-01-07 15:03 UTC (permalink / raw) To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 2549 bytes --] On Mon, Jan 6, 2020 at 9:32 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote: > > but…damn, even ex/vi 3.x is huge > > It was so excesssive right from the start that I refused to use it. > Sam was the first screen editor that I deemed worthwhile, and I > still use it today. > > Doug > Oh so true; although the early version from 2BSD was smaller. I bet my fingers are still only using much of that subset ;-) But I certainly watched it grow and grow over the years. I'm really not so sure about 'vim' -- it has become as much of a feature sink as emacs. FWIW: When I went from PDP-10 land to UNIX, I learned ed for 5th edition and somewhat pined for a screen editor. Soon after upgrading to 6th edition at CMU, we found a visual editor called Fred - the Friendly Editor, from Cornell IIRC (I think it's on the original USENIX tape but I don't remember how we got it). I had to hack in the Perkin-Elmer Fox terminal support, but it was a superset of V6 ed so a pretty trivial learning curve. However, since Fred had the terminal support compiled it and when I went to Tektronix a few years later, I had to add a whole bunch of new terminals and we quickly started running into the address issues on the 11/40 class systems. Mark Bales was working as a summer student and had brought 2BSD with him (inc. vi and csh). Poof, thanks to termcap ex/vi could run on most every terminal we already had (in some manner) which Fred could not. And because of termcap not having to keep the code for the other terminals not being used in memory, even though the editor itself was more complex, we could just squeeze that version on an 11/40 class system running Seventh Edition. That made me take notice. Again it was ed under the covers so the transition was easy. I was pretty impressed with termcap, and soon thereafter I found myself sending Mary Ann a couple of new terminal definitions for some missing Tek terminals like Tek 4025. With the VAX, and new ex/vi shows up and it would not run on the PDP-11's, I was disappointed. But the old version still worked and I had started to notice that a *version of **vi *had started to show up on most everything I used, from VMS to the Cray's and later the PCs, so really I never looked back. It became the most portable editor for my fingers as I had long ago forgotten EMACS (even when we got Vaxen and Gosling EMACS shows up on the UNIX scene, I never bother to really relearn it - I can use it if I have too, but not as well as vi these days). [-- Attachment #2: Type: text/html, Size: 5314 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors (FRED) 2020-01-07 15:03 ` Clem Cole @ 2020-01-08 21:43 ` Greg A. Woods 2020-01-09 0:04 ` Dave Horsfall 0 siblings, 1 reply; 118+ messages in thread From: Greg A. Woods @ 2020-01-08 21:43 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 4842 bytes --] At Tue, 7 Jan 2020 10:03:57 -0500, Clem Cole <clemc@ccc.com> wrote: Subject: Re: [TUHS] screen editors > > FWIW: When I went from PDP-10 land to UNIX, I learned ed for 5th edition > and somewhat pined for a screen editor. Soon after upgrading to 6th > edition at CMU, we found a visual editor called Fred - the Friendly Editor, > from Cornell IIRC (I think it's on the original USENIX tape but I don't > remember how we got it). I had to hack in the Perkin-Elmer Fox terminal > support, but it was a superset of V6 ed so a pretty trivial learning curve. Ah, yes, Fred. A name with so many editors! I used a full-screen version of an ed-like editor on V7, 32B, and 4BSD at University of Calgary which was called the "FRiendly EDitor". This may be the one you mention. The FRED I know is not to be confused with the version of QED named FRED (Friendly Editor) that was written at the University of Waterloo for Honeywell GECOS by Peter Fraser. It's also not the "FRED - A Friendly Editor" by Richard J. Botting [1]. There's also apparently an editor named FRED for VMS, and another for Amstrad PCW systems (for editing BASIC, and apparently written in BASIC itself). And then there's the one from a company called Digitool which was called "FRED: Fred Resembles Emacs Deliberately", which was written in Macintosh Common Lisp. There's also an old Windows-based "Friendly Right-to-Left Editor (FRED)" by NSRI. I also recently found this [2] reference to a "FRED", but it seems to be yet another completely different kind of editor using the same name. [1] http://www.csci.csusb.edu/dick/papers/rjb84a.FRED.mth [2] https://www.osti.gov/biblio/5141603-fred-program-development-tool Abstract: The structured, screen-based editor FRED is introduced. FRED provides incremental parsing and semantic analysis. The parsing is based on an LL(1) top-down algorithm which has been modified to provide follow-the-cursor parsing and soft templates. The languages accepted by the editor are LL(1) languages with the addition of the Unknown and preferred production non-terminal classes. The semantic analysis is based on the incremental update of attribute grammar equations. We briefly describe the interface between FRED and an automated reference librarian system that is under development. FRED User's Manual Shilling, J. Illinois University, Urbana Department of Computer Science Feb. 1984 FRED, the frinedly editor, is a screen-based structured editor. This manual is intended to serve the needs of a wide range of users of the FRED text editor. Most users will find it sufficient to read the introductory material in section 2, supplemented with the full command set description in section 3. Advanced users may wish to change the keystroke sequences which invoke editor commands. Section 4 describes how to change key bindings and how to define command macros. Some users may need to modify a language description or create an entirely new language description for use with FRED. Section 5 describes the format of the language descriptions used by the editor, and describes how to construct a language grammar. Section 6 describes known portability problems of the FRED editor and should concern only system installation personnel. The editor points out syntax errors in the file being edited and does automatic pretty printing. The version of Fred I used had a full-screen line-oriented mode as well as what was called "open" mode which presented a much more direct full-screen editing experience (though it was a bit quirky, but it reminded me a bit of "Electric Pencil II" which I had used on a Sol-20). Open mode of course generated an interrupt for every key press and so on a PDP-11/60 with 16 terminals it could cause quite a system load, and most of us avoided using open mode on the PDPs. Even the VAX 11/780 running 32V was sometimes slowed by it, but it had at least 24 terminals as I recall (at the time it was still running 32V), so a room full of students feverously typing away was quite a lot of input. I've been unable to find any other reference or mention of this version of Fred; and to the best of my searches it's not on any Usenix tape I can find a copy of. If anyone has any further info about the FRED Clem and/or I seem to remember, please do post it! I soon forgot most that I knew about Fred though once Gosling Emacs was installed on the VAX (after it had been upgraded to 4BSD). I already had a strong preference to Emacs having used it extensively on the Multics system at UofC. -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors (FRED) 2020-01-08 21:43 ` [TUHS] screen editors (FRED) Greg A. Woods @ 2020-01-09 0:04 ` Dave Horsfall 0 siblings, 0 replies; 118+ messages in thread From: Dave Horsfall @ 2020-01-09 0:04 UTC (permalink / raw) To: The Unix Heritage Society mailing list I'm surprised that no-one has mentioned "F*cking Ripper of an EDitor" yet, or was it UNSW-only? -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 2:31 [TUHS] screen editors Doug McIlroy ` (4 preceding siblings ...) 2020-01-07 15:03 ` Clem Cole @ 2020-01-07 15:50 ` Thomas Paulsen 2020-01-07 20:45 ` Chet Ramey 5 siblings, 1 reply; 118+ messages in thread From: Thomas Paulsen @ 2020-01-07 15:50 UTC (permalink / raw) To: Doug McIlroy; +Cc: tuhs >It was so excesssive right from the start that I refused to use it. >Sam was the first screen editor that I deemed worthwhile, and I >still use it today. my sam build is more than 2 times bigger than Gunnar Ritter's vi (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 15:50 ` [TUHS] screen editors Thomas Paulsen @ 2020-01-07 20:45 ` Chet Ramey 2020-01-07 21:20 ` Derek Fawcus 0 siblings, 1 reply; 118+ messages in thread From: Chet Ramey @ 2020-01-07 20:45 UTC (permalink / raw) To: Thomas Paulsen, Doug McIlroy; +Cc: tuhs On 1/7/20 10:50 AM, Thomas Paulsen wrote: >> It was so excesssive right from the start that I refused to use it. >> Sam was the first screen editor that I deemed worthwhile, and I >> still use it today. > my sam build is more than 2 times bigger than Gunnar Ritter's vi (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim. If we're really doing this editor size contest thing, I'll submit my `ce' editor. (ftp://ftp.cwru.edu/pub/chet/ce-4.8.tar.gz). It's emacs-like, but not particularly configurable, and the defaults, strangely enough, are exactly what I like. On my Mac OS X machine, it's about ten times smaller than vim $ size /usr/local/bin/ce __TEXT __DATA __OBJC others dec hex 114688 339968 0 4295024640 4295479296 10007d000 $ size /usr/bin/vim __TEXT __DATA __OBJC others dec hex 1687552 176128 0 4295016448 4296880128 1001d3000 Similar numbers on RHEL 7, but due to the large bss, it's only about 45% smaller than vim. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 20:45 ` Chet Ramey @ 2020-01-07 21:20 ` Derek Fawcus 0 siblings, 0 replies; 118+ messages in thread From: Derek Fawcus @ 2020-01-07 21:20 UTC (permalink / raw) To: tuhs On Tue, Jan 07, 2020 at 03:45:24PM -0500, Chet Ramey wrote: > On my Mac OS X machine, it's about ten times smaller than vim > > $ size /usr/local/bin/ce > __TEXT __DATA __OBJC others dec hex > 114688 339968 0 4295024640 4295479296 10007d000 > $ size /usr/bin/vim > __TEXT __DATA __OBJC others dec hex > 1687552 176128 0 4295016448 4296880128 1001d3000 > > Similar numbers on RHEL 7, but due to the large bss, it's only about > 45% smaller than vim. So I got curious about those large numbers on the mac, and made use of 'otool -l'. It would seem that the values for __DATA reported by size correspond to the overall size of the 'load command' for the __DATA segment, and so includes bss as well. $ ls -l /usr/bin/vim -rwxr-xr-x 1 root wheel 1530064 29 Jun 2018 /usr/bin/vim So 'size' on the mac is not so useful, but 'size -m /usr/bin/vim' gives information from which one could derive the normal 'size' output. $ size -m /usr/bin/vim Segment __PAGEZERO: 4294967296 Segment __TEXT: 1388544 Section __text: 1271745 Section __stubs: 1044 Section __stub_helper: 1756 Section __cstring: 85892 Section __const: 14672 Section __unwind_info: 8944 total 1384053 Segment __DATA: 155648 Section __got: 1056 Section __nl_symbol_ptr: 16 Section __la_symbol_ptr: 1392 Section __const: 38608 Section __data: 64432 Section __bss: 42520 Section __common: 5720 total 153744 Segment __LINKEDIT: 36864 total 4296548352 DF ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors @ 2020-01-07 19:57 Doug McIlroy 2020-01-07 20:17 ` Brantley Coile 2020-01-07 20:47 ` Bakul Shah 0 siblings, 2 replies; 118+ messages in thread From: Doug McIlroy @ 2020-01-07 19:57 UTC (permalink / raw) To: tuhs, thomas.paulsen McIlroy: > [vi] was so excesssive right from the start that I refused to use it. > Sam was the first screen editor that I deemed worthwhile, and I > still use it today. Paulsen: > my sam build is more than 2 times bigger than Gunnar Ritter's vi > (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim. % wc -c /bin/vi bin/sam bin/samterm 1706152 /bin/vi 112208 bin/sam 153624 bin/samterm These mumbers are from Red Hat Linux. The 6:1 discrepancy is understated because vi is stripped and the sam files are not. All are 64-bit, dynamically linked. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 19:57 Doug McIlroy @ 2020-01-07 20:17 ` Brantley Coile 2020-01-07 20:47 ` Bakul Shah 1 sibling, 0 replies; 118+ messages in thread From: Brantley Coile @ 2020-01-07 20:17 UTC (permalink / raw) To: Doug McIlroy; +Cc: tuhs No point here, other than showing the size of sam in its native Plan 9 habitat. ehg% size /bin/sam /bin/aux/samterm 95,514t + 8,764d + 75,868b = 180,146 /bin/sam 145,093t + 28,708d + 59,508b = 233,309 /bin/aux/samterm The size gives me a better idea of the code complexity. For completeness, here's the size of vi on my Mac. bwc-downtown:~ bwc$ size /usr/bin/vi __TEXT __DATA __OBJC others dec hex 1,585,152 163,840 0 4,295,012,352 4,296,761,344 1001b6000 Good thing the Mac has shared libraries? (Commas added for clarity) Again, no point, other than a data point. Brantley > On Jan 7, 2020, at 2:57 PM, Doug McIlroy <doug@cs.dartmouth.edu> wrote: > > McIlroy: >> [vi] was so excesssive right from the start that I refused to use it. >> Sam was the first screen editor that I deemed worthwhile, and I >> still use it today. > > Paulsen: >> my sam build is more than 2 times bigger than Gunnar Ritter's vi >> (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim. > > % wc -c /bin/vi bin/sam bin/samterm > 1706152 /bin/vi > 112208 bin/sam > 153624 bin/samterm > These mumbers are from Red Hat Linux. > The 6:1 discrepancy is understated because > vi is stripped and the sam files are not. > All are 64-bit, dynamically linked. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-07 19:57 Doug McIlroy 2020-01-07 20:17 ` Brantley Coile @ 2020-01-07 20:47 ` Bakul Shah 1 sibling, 0 replies; 118+ messages in thread From: Bakul Shah @ 2020-01-07 20:47 UTC (permalink / raw) To: tuhs On Tue, 07 Jan 2020 14:57:40 -0500 Doug McIlroy <doug@cs.dartmouth.edu> wrote: > McIlroy: > > [vi] was so excesssive right from the start that I refused to use it. > > Sam was the first screen editor that I deemed worthwhile, and I > > still use it today. > > Paulsen: > > my sam build is more than 2 times bigger than Gunnar Ritter's vi > > (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim. > > % wc -c /bin/vi bin/sam bin/samterm > 1706152 /bin/vi > 112208 bin/sam > 153624 bin/samterm > These mumbers are from Red Hat Linux. > The 6:1 discrepancy is understated because > vi is stripped and the sam files are not. > All are 64-bit, dynamically linked. A source code comparison $ cd 2bsd/src/ex # this is a snapshot of May 9, 1979 $ wc *.c | tail -1 17176 56138 331865 total $ cd $PLAN9/src/cmd/ # what works today $ wc {sam,samterm}/*.[hc] | tail -1 11366 27236 201666 total $ cd /usr/src/contrib/nvi # what works today $ wc */*.[ch] | tail -1 51978 202926 1297043 total # actual count is slightly smaller I use nvi or acme. Haven't touched sam in ages. Having taught my fingertips nvi 37 years back, I can edit the fastest in it. But some things are easier in acme + with its multiple panes and smaller antialiased fonts it makes much better use of a retina display. iterm/screen + nvi can't match that. Until about 95 I used nvi & the Rand Editor (later Dave Yost's version). The latter was the easiest to use + it did multiple editing windows much before nvi or vim. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors
@ 2020-01-08 7:39 Thomas Paulsen
2020-01-08 15:58 ` Steve Nickolas
2020-01-08 21:49 ` Dave Horsfall
0 siblings, 2 replies; 118+ messages in thread
From: Thomas Paulsen @ 2020-01-08 7:39 UTC (permalink / raw)
To: arnold; +Cc: tuhs
>What's funny is that in doing the work to get 'se' running on Georgia
>Tech's Vax, I had to learn vi. By the time I was done, vi had become
>my main editor and had burned itself into my finger's ROMs.
I do ed/se occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all bigger projects, beside liteide for golang.
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 7:39 Thomas Paulsen @ 2020-01-08 15:58 ` Steve Nickolas 2020-01-08 23:41 ` Dave Horsfall 2020-01-08 21:49 ` Dave Horsfall 1 sibling, 1 reply; 118+ messages in thread From: Steve Nickolas @ 2020-01-08 15:58 UTC (permalink / raw) To: Thomas Paulsen; +Cc: tuhs On Wed, 8 Jan 2020, Thomas Paulsen wrote: >> What's funny is that in doing the work to get 'se' running on Georgia >> Tech's Vax, I had to learn vi. By the time I was done, vi had become >> my main editor and had burned itself into my finger's ROMs. > I do ed/se occasionally for simple tasks, vim frequently , because it > loads fast, and emacs for all bigger projects, beside liteide for > golang. For what it's worth, I use nano. (Yeah, I know, not very unixy.) I think the first fullscreen text editor I used was FrEdWriter (by Paul Lutus and Al Rogers) for the Apple ][. After that it was IBM's E. I haven't really used vi *or* emacs much. -uso. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 15:58 ` Steve Nickolas @ 2020-01-08 23:41 ` Dave Horsfall 2020-01-09 1:43 ` Nemo Nusquam 0 siblings, 1 reply; 118+ messages in thread From: Dave Horsfall @ 2020-01-08 23:41 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Wed, 8 Jan 2020, Steve Nickolas wrote: > I think the first fullscreen text editor I used was FrEdWriter (by Paul > Lutus and Al Rogers) for the Apple ][. After that it was IBM's E. I > haven't really used vi *or* emacs much. First I used was DEC's "EDT" and could never get used to the "gold" key... Fortunately I was not required to use RSX (or was it VMS?) as I was strictly a PDP Unix bod at the time; I was just curious. -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 23:41 ` Dave Horsfall @ 2020-01-09 1:43 ` Nemo Nusquam 0 siblings, 0 replies; 118+ messages in thread From: Nemo Nusquam @ 2020-01-09 1:43 UTC (permalink / raw) To: tuhs On 01/08/20 18:41, Dave Horsfall wrote: > [...] > First I used was DEC's "EDT" and could never get used to the "gold" > key... > > Fortunately I was not required to use RSX (or was it VMS?) as I was > strictly a PDP Unix bod at the time; I was just curious. > > -- Dave It was VMS and I had forgotten all about the Gold Key until now. N. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 7:39 Thomas Paulsen 2020-01-08 15:58 ` Steve Nickolas @ 2020-01-08 21:49 ` Dave Horsfall 2020-01-08 22:01 ` Clem Cole 2020-01-10 8:13 ` markus schnalke 1 sibling, 2 replies; 118+ messages in thread From: Dave Horsfall @ 2020-01-08 21:49 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Wed, 8 Jan 2020, Thomas Paulsen wrote: > I do ed/se occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all bigger projects, beside liteide for golang. I had a boss once who insisted that all his staff learn "ed", because one day it might be the only editor available; he was right... -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 21:49 ` Dave Horsfall @ 2020-01-08 22:01 ` Clem Cole 2020-01-17 23:38 ` Dave Horsfall 2020-01-10 8:13 ` markus schnalke 1 sibling, 1 reply; 118+ messages in thread From: Clem Cole @ 2020-01-08 22:01 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 740 bytes --] On Wed, Jan 8, 2020 at 4:50 PM Dave Horsfall <dave@horsfall.org> wrote: > I had a boss once who insisted that all his staff learn "ed", because one > day it might be the only editor available; he was right... > I always suggest it. It means you can use sed and lot of other tools pretty quick. And if you know ed, you can use almost anything close to it. I hated DOS's edlin but if I was stuck it was close enough. Although the famous ? error from the original version was annoying. Truly, I still suggest that any modern user, take Rob and Brian's book and until you can do the exercises without think about it, you really are not yet comfortable with UNIX. I even recommend at least read and looking at the chapter on nroff. Clem [-- Attachment #2: Type: text/html, Size: 1823 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 22:01 ` Clem Cole @ 2020-01-17 23:38 ` Dave Horsfall 2020-01-18 0:07 ` Ryan Casalino 2020-01-18 23:02 ` greg travis 0 siblings, 2 replies; 118+ messages in thread From: Dave Horsfall @ 2020-01-17 23:38 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Wed, 8 Jan 2020, Clem Cole wrote: > Although the famous ? error from the original version was annoying. Was it Ken or Dennis who thought of a car with but a single alarm indicator; "the experienced driver will know what it means". -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-17 23:38 ` Dave Horsfall @ 2020-01-18 0:07 ` Ryan Casalino 2020-01-18 23:02 ` greg travis 1 sibling, 0 replies; 118+ messages in thread From: Ryan Casalino @ 2020-01-18 0:07 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 540 bytes --] On Fri, Jan 17, 2020, at 3:38 PM, Dave Horsfall wrote: > On Wed, 8 Jan 2020, Clem Cole wrote: > > > Although the famous ? error from the original version was annoying. > > Was it Ken or Dennis who thought of a car with but a single alarm > indicator; "the experienced driver will know what it means". > > -- Dave > I actually just started using ed for the first time last week (based on one of your earlier comments, Clem) and I couldn't disagree more. ? is refreshing in its simplicity. Anyway, back to being a fly on the wall. :) [-- Attachment #2: Type: text/html, Size: 989 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-17 23:38 ` Dave Horsfall 2020-01-18 0:07 ` Ryan Casalino @ 2020-01-18 23:02 ` greg travis 1 sibling, 0 replies; 118+ messages in thread From: greg travis @ 2020-01-18 23:02 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 735 bytes --] 'Ken Thompson has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the other numerous idiot lights which plague the modern driver. Rather, if the driver makes a mistake, a giant “?” lights up in the center of the dashboard. “The experienced driver,” says Thompson, “will usually know what’s wrong.”' On Fri, Jan 17, 2020 at 6:39 PM Dave Horsfall <dave@horsfall.org> wrote: > On Wed, 8 Jan 2020, Clem Cole wrote: > > > Although the famous ? error from the original version was annoying. > > Was it Ken or Dennis who thought of a car with but a single alarm > indicator; "the experienced driver will know what it means". > > -- Dave > [-- Attachment #2: Type: text/html, Size: 1170 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 21:49 ` Dave Horsfall 2020-01-08 22:01 ` Clem Cole @ 2020-01-10 8:13 ` markus schnalke 2020-01-10 8:17 ` U'll Be King of the Stars ` (2 more replies) 1 sibling, 3 replies; 118+ messages in thread From: markus schnalke @ 2020-01-10 8:13 UTC (permalink / raw) To: tuhs Hoi. [2020-01-09 08:49] Dave Horsfall <dave@horsfall.org> > On Wed, 8 Jan 2020, Thomas Paulsen wrote: > > > I do ed/se occasionally for simple tasks, vim frequently , > > because it loads fast, and emacs for all bigger projects, > > beside liteide for golang. > > I had a boss once who insisted that all his staff learn "ed", > because one day it might be the only editor available; he was > right... On a modern Linux system, ed isn't even installed ... 8-O I was quite shocked when I first realized that I had to do `apt-get install ed' to have it available ... on a Unix-like system. But on the other hand, who of today's users is even capable of exiting it?! On my own systems I like to install Heirlomm ed, which I have outfactored from the Heirloom tools package. If you want to actually use it every now and then, Gunnar's ed is much more usable than GNU ed ... which seems to be more a demonstration object than actually a programmer's editor. Anyways, I'm having a great pleasure reading those historic spotlights on editors these days. :-) meillo ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-10 8:13 ` markus schnalke @ 2020-01-10 8:17 ` U'll Be King of the Stars 2020-01-11 19:58 ` markus schnalke 2020-01-10 15:31 ` Nemo Nusquam 2020-01-10 15:58 ` Theodore Y. Ts'o 2 siblings, 1 reply; 118+ messages in thread From: U'll Be King of the Stars @ 2020-01-10 8:17 UTC (permalink / raw) To: markus schnalke, tuhs On 10/01/2020 08:13, markus schnalke wrote: > GNU ed [...] seems to be more a demonstration > object than actually a programmer's editor. Hi Markus, in what way is GNU ed a "demonstration object"? Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-10 8:17 ` U'll Be King of the Stars @ 2020-01-11 19:58 ` markus schnalke 2020-01-11 20:54 ` Derek Fawcus ` (2 more replies) 0 siblings, 3 replies; 118+ messages in thread From: markus schnalke @ 2020-01-11 19:58 UTC (permalink / raw) To: tuhs Hoi. [2020-01-10 08:17] U'll Be King of the Stars <ullbeking@andrewnesbit.org> > On 10/01/2020 08:13, markus schnalke wrote: > > > > GNU ed [...] seems to be more a demonstration > > object than actually a programmer's editor. > > Hi Markus, in what way is GNU ed a "demonstration object"? Thanks for questioning this statement! It seems as if I might have mixed different memories up. A quick look at GNU ed showed nothing to support my statement. Sorry for pretending stuff without fact checking. My look was at version 1.4, which is the newest one I could look into. I'm pretty sure I examined GNU ed 1.6 back then, because that version is in the Pkgfile of my system, but unfortunately I am unable to find it anywhere. The GNU release mirrors lack all version 1.5 through 1.10 -- why that? They must have been released, at least 1.6, because that is used on my system. Unfortunately I also was unable to access the Changelog of a newer version to check for changes, because these are lzip compressed (tar.lz) ... whatever that is, I cannot uncompress it on my system. Furthermore I neither could find an online browsable web repo view for checking out version 1.6 or at least viewing the files within the browser. There's only a cvs repo access (no cvs on my machine) and it talks about the web page repo not the ed source repo. Not sure what to think of that. That's not how things should be. Actually, I'm a bit depressed now ... meillo P.S. Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like ``vee-eye''), is that what you english speakers do? To me (a native German speaker) it naturally was ``ed'' (like ``sam''). As reference some Computerphile video is given, which is now deleted. Is there a better source? And what about the pronounciations of `ex' and `qed'? What about `od'? (That I pronouce ``oh-dee''.) https://en.wikipedia.org/wiki/Ed_(text_editor) ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-11 19:58 ` markus schnalke @ 2020-01-11 20:54 ` Derek Fawcus 2020-01-11 21:27 ` Henry Bent 2020-02-04 8:40 ` Sijmen J. Mulder 2 siblings, 0 replies; 118+ messages in thread From: Derek Fawcus @ 2020-01-11 20:54 UTC (permalink / raw) To: tuhs On Sat, Jan 11, 2020 at 08:58:53PM +0100, markus schnalke wrote: > > Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like > ``vee-eye''), is that what you english speakers do? To me (a > native German speaker) it naturally was ``ed'' (like ``sam''). As a native english speaker... 'ed', as in the man's name. I pronounce 'vi' as you have it above, but others at work pronounce it as 'vye' (as in 'vying'), so no consistency there. We also have local inconsistencies for how JIRA is pronounced, so don't expect a canonical answer. > And what about the pronounciations of `ex' and `qed'? I can't say I've pronounced them before, but I think of former as 'ee-x', I'd be inclined to pronounce the latter as 'queue-ed'. Since Q-E-D has its own meaning. > What about `od'? (That I pronouce ``oh-dee''.) agreed; otherwise confusing with 'odd'. But who knows how the authors pronounced them. DF ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-11 19:58 ` markus schnalke 2020-01-11 20:54 ` Derek Fawcus @ 2020-01-11 21:27 ` Henry Bent 2020-02-04 8:40 ` Sijmen J. Mulder 2 siblings, 0 replies; 118+ messages in thread From: Henry Bent @ 2020-01-11 21:27 UTC (permalink / raw) To: markus schnalke; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 3161 bytes --] On Sat, 11 Jan 2020 at 14:59, markus schnalke <meillo@marmaro.de> wrote: > Hoi. > > [2020-01-10 08:17] U'll Be King of the Stars <ullbeking@andrewnesbit.org> > > On 10/01/2020 08:13, markus schnalke wrote: > > > > > > GNU ed [...] seems to be more a demonstration > > > object than actually a programmer's editor. > > > > Hi Markus, in what way is GNU ed a "demonstration object"? > > Thanks for questioning this statement! It seems as if I might have > mixed different memories up. A quick look at GNU ed showed nothing > to support my statement. Sorry for pretending stuff without fact > checking. > > > My look was at version 1.4, which is the newest one I could look > into. I'm pretty sure I examined GNU ed 1.6 back then, because > that version is in the Pkgfile of my system, but unfortunately I > am unable to find it anywhere. The GNU release mirrors lack all > version 1.5 through 1.10 -- why that? They must have been > released, at least 1.6, because that is used on my system. > Unfortunately I also was unable to access the Changelog of a > newer version to check for changes, because these are lzip > compressed (tar.lz) ... whatever that is, I cannot uncompress it > on my system. Furthermore I neither could find an online > browsable web repo view for checking out version 1.6 or at least > viewing the files within the browser. There's only a cvs repo > access (no cvs on my machine) and it talks about the web page > repo not the ed source repo. Not sure what to think of that. > > That's not how things should be. Actually, I'm a bit depressed > now ... > GNU ed appears to be written entirely by one person (as in, no changelog entries by anyone else since 1994), who perhaps not coincidentally is also the author of the lzip compression program. As you noted, ed source is distributed only as lzip-compressed tarballs, so you have to be able to compile and run lzip to compile and run ed. lzip is written in C++, so to have access to GNU ed you need a C++ compiler. Which is very strange, as GNU ed is a very simple C program, much as one would expect. The configure program is extremely basic, which is great - why have more than you need? - but when it detected that my $(CC) was not gcc, it hard-coded $(CC) to cc and $(CFLAGS) to -O2, ignoring what I had passed to the script. A strange choice, but one that can easily be edited later in the Makefile. The basic C source compiled with no warnings whatsoever, always a good sign. At the linking stage I noticed that I needed a library for some functions it wanted. Okay, easy enough, just add a library to the Makefile's LDFLAGS. But the Makefile had this braindamage: $(progname) : $(objs) $(CC) $(LDFLAGS) $(CFLAGS) -o $@ $(objs) so on any platform that needs libraries linked after objects, it will fail. At that point, I gave up. This is clearly one person's pet project and has "but it works on my Linux box!" written all over it. That, coupled with the fact that the GNU folks are willing to endorse something that is solely distributed in what can only be described as an extremely obscure compression format, was just too much for me to handle. -Henry [-- Attachment #2: Type: text/html, Size: 3832 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-11 19:58 ` markus schnalke 2020-01-11 20:54 ` Derek Fawcus 2020-01-11 21:27 ` Henry Bent @ 2020-02-04 8:40 ` Sijmen J. Mulder 2 siblings, 0 replies; 118+ messages in thread From: Sijmen J. Mulder @ 2020-02-04 8:40 UTC (permalink / raw) To: markus schnalke; +Cc: tuhs markus schnalke <meillo@marmaro.de> wrote: > Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like > ``vee-eye''), is that what you english speakers do? To me (a > native German speaker) it naturally was ``ed'' (like ``sam''). > As reference some Computerphile video is given, which is now > deleted. Is there a better source? Dutch speaker. ed: Hi Ed vi: C'est la vie Bonus: chroot: shroot These may not be the proper pronunciations but I like the names best this way. Sijmen ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-10 8:13 ` markus schnalke 2020-01-10 8:17 ` U'll Be King of the Stars @ 2020-01-10 15:31 ` Nemo Nusquam 2020-01-10 16:04 ` Clem Cole 2020-01-10 17:10 ` Dan Cross 2020-01-10 15:58 ` Theodore Y. Ts'o 2 siblings, 2 replies; 118+ messages in thread From: Nemo Nusquam @ 2020-01-10 15:31 UTC (permalink / raw) To: tuhs On 01/10/20 03:13, markus schnalke wrote (in part): > Hoi. [...] > Anyways, I'm having a great pleasure reading those historic > spotlights on editors these days. :-) In earlier days, my wife was given email by telnetting to an SGI system and using elm. One day, I visited her office as she was composing a message. Intrigued, I asked her what the editor was. She did not know and pointed to her cheat-sheet listing editor commands. One was ^X^C to exit-and-send. She is not a programmer and I was a bit surprised at their choice. N. > > > meillo ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-10 15:31 ` Nemo Nusquam @ 2020-01-10 16:04 ` Clem Cole 2020-01-10 17:10 ` Dan Cross 1 sibling, 0 replies; 118+ messages in thread From: Clem Cole @ 2020-01-10 16:04 UTC (permalink / raw) To: Nemo Nusquam; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1345 bytes --] On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam <cym224@gmail.com> wrote: > Intrigued, I asked her what the editor was. She did not know > and pointed to her cheat-sheet listing editor commands. One was ^X^C to > exit-and-send. She is not a programmer and I was a bit surprised at > their choice. > Similar fun Unix/ITS emacs story. In the mid/later 1970s, my least techie sister Cynthia was/is a concert harpist with a degree from Oberlin's conservatory. She can type extremely fast as she has super manual dexterity. But playing the harp is not something that paid a great deal or offered her 'regular' gigs, so to make the monthly rent she got a job working at MIT as Ron Rivest's admin . She typed all the RSA papers in emacs and tex on one of the MIT systems. She did not know any better, that's what they gave her/taught her. When she later would look for a job at other places and they would ask her, 'do you know how to use a Wang System' and she would say: "No, I know emacs" [for the younger set, longer before MS-Word, "Wang" was synonymous with "word processor" and many/most commercial offices had a 'Wang unit" for the folks doing the typing.]. [As a side note when she found out the elevators were hacked and controlled by the student's different computers, she stopped using them and would take the stairs in Tech Sq]. [-- Attachment #2: Type: text/html, Size: 2373 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-10 15:31 ` Nemo Nusquam 2020-01-10 16:04 ` Clem Cole @ 2020-01-10 17:10 ` Dan Cross 2020-01-10 17:18 ` Steve Nickolas 1 sibling, 1 reply; 118+ messages in thread From: Dan Cross @ 2020-01-10 17:10 UTC (permalink / raw) To: Nemo Nusquam; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 991 bytes --] On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam <cym224@gmail.com> wrote: > In earlier days, my wife was given email by telnetting to an SGI system > and using elm. One day, I visited her office as she was composing a > message. Intrigued, I asked her what the editor was. She did not know > and pointed to her cheat-sheet listing editor commands. One was ^X^C to > exit-and-send. She is not a programmer and I was a bit surprised at > their choice. > Hmm, I'm actually kind of not. Starting users off with a modal editor (that starts in command mode, no less!) can be surprising for novices; with emacs, at least you can start typing text and, well, see text. I think that one of the smartest things Marc Crispin ever did was write `pico` to go with `pine`. A simple editor targeted at the novice was really useful for casual and/or new users, particularly as the Internet spread and an account on a Unix system was the default introduction to email etc for so many. - Dan C. [-- Attachment #2: Type: text/html, Size: 1364 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-10 17:10 ` Dan Cross @ 2020-01-10 17:18 ` Steve Nickolas 2020-01-18 1:55 ` Michael Parson 0 siblings, 1 reply; 118+ messages in thread From: Steve Nickolas @ 2020-01-10 17:18 UTC (permalink / raw) To: Dan Cross; +Cc: TUHS main list On Fri, 10 Jan 2020, Dan Cross wrote: > On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam <cym224@gmail.com> wrote: > >> In earlier days, my wife was given email by telnetting to an SGI system >> and using elm. One day, I visited her office as she was composing a >> message. Intrigued, I asked her what the editor was. She did not know >> and pointed to her cheat-sheet listing editor commands. One was ^X^C to >> exit-and-send. She is not a programmer and I was a bit surprised at >> their choice. >> > > Hmm, I'm actually kind of not. Starting users off with a modal editor (that > starts in command mode, no less!) can be surprising for novices; with > emacs, at least you can start typing text and, well, see text. This is one of the reasons I liked E when I first used it: it was modal, but it started in edit mode. (Also you KNEW what mode you were in, which I understand isn't always the case with vi, although it usually is in the clones iirc?) > I think that one of the smartest things Marc Crispin ever did was write > `pico` to go with `pine`. A simple editor targeted at the novice was really > useful for casual and/or new users, particularly as the Internet spread and > an account on a Unix system was the default introduction to email etc for > so many. And I still use nano - which is a rewrite of pico. pico Just Works(R)(TM)(C), and it's not enormous. nano adds a few things I like, but the UI is the same. Heck...I still use PINE and am sending this message from it ;) -uso. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-10 17:18 ` Steve Nickolas @ 2020-01-18 1:55 ` Michael Parson 0 siblings, 0 replies; 118+ messages in thread From: Michael Parson @ 2020-01-18 1:55 UTC (permalink / raw) To: TUHS main list On Fri, 10 Jan 2020, Steve Nickolas wrote: > On Fri, 10 Jan 2020, Dan Cross wrote: >> On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam <cym224@gmail.com> >> wrote: >> >>> In earlier days, my wife was given email by telnetting to an SGI >>> system and using elm. One day, I visited her office as she was >>> composing a message. Intrigued, I asked her what the editor >>> was. She did not know and pointed to her cheat-sheet listing editor >>> commands. One was ^X^C to exit-and-send. She is not a programmer >>> and I was a bit surprised at their choice. >> >> >> Hmm, I'm actually kind of not. Starting users off with a modal >> editor (that starts in command mode, no less!) can be surprising for >> novices; with emacs, at least you can start typing text and, well, >> see text. > > This is one of the reasons I liked E when I first used it: it was > modal, but it started in edit mode. (Also you KNEW what mode you were > in, which I understand isn't always the case with vi, although it > usually is in the clones iirc?) > >> I think that one of the smartest things Marc Crispin ever did was >> write `pico` to go with `pine`. A simple editor targeted at the >> novice was really useful for casual and/or new users, particularly as >> the Internet spread and an account on a Unix system was the default >> introduction to email etc for so many. > > And I still use nano - which is a rewrite of pico. The 'gnu' version (or maybe just gnu licensed) of pico, cuz there has to be a 'gnu' licensed of everything :-/ > pico Just Works(R)(TM)(C), and it's not enormous. nano adds a few things I > like, but the UI is the same. Heck...I still use PINE and am sending this > message from it ;) I used pine for years, now alpine, fingers are as hard wired for moving around in it as they are for doing things in vi(m). However, I also have (al)pine use vi for the message editing. :) I learned ed a long time ago because I once had some box that would boot into single-user mode, but not far enough to get any termcap/info stuff loaded, vi didn't work, ex didn't work, but ed did. Not too long ago, I used ed to fix a hosed up passwd file via salt... did something like: sudo salt some-box cmd.run 'printf "1\n/mparson\ns/foo/bar/\nw\nq\n" | ed /etc/passwd' I don't remember what exactly was wrong, but it prevented someone from being able to log in and it wasn't fixable with the 'users' state. Maybe it was a bad path to root's shell and we couldn't log in on the console or something. I've slept since then, lost the details. The guy watching over my shoulder didn't even know what 'ed' was. -- Michael Parson Pflugerville, TX KF5LGQ ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-10 8:13 ` markus schnalke 2020-01-10 8:17 ` U'll Be King of the Stars 2020-01-10 15:31 ` Nemo Nusquam @ 2020-01-10 15:58 ` Theodore Y. Ts'o 2 siblings, 0 replies; 118+ messages in thread From: Theodore Y. Ts'o @ 2020-01-10 15:58 UTC (permalink / raw) To: markus schnalke; +Cc: tuhs On Fri, Jan 10, 2020 at 09:13:04AM +0100, markus schnalke wrote: > > I was quite shocked when I first realized that I had to do > `apt-get install ed' to have it available ... on a Unix-like > system. But on the other hand, who of today's users is even > capable of exiting it?! For what it's worth, I regularly edit configuration files and shell scripts using /bin/ed in environments where I can't use (due to terminal limitations) or can't fit a more sophisticated editors. These days this is typically in small appliance VM's. I've also been known to do things like this in shell scripts[1]: ed /etc/lighttpd/lighttpd.conf <<EOF /^server.document-root/s/^/#/p /^index-file.names/s/^/#/p /^include_shell.*create-mime/s/^/#/p w q EOF [1] https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/gce-xfstests-bld.sh And for years, I knew how to exit ed and emacs, but had trouble exiting vi. :-) - Ted > > > On my own systems I like to install Heirlomm ed, which I have > outfactored from the Heirloom tools package. If you want to > actually use it every now and then, Gunnar's ed is much more > usable than GNU ed ... which seems to be more a demonstration > object than actually a programmer's editor. > > > Anyways, I'm having a great pleasure reading those historic > spotlights on editors these days. :-) > > > meillo ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors @ 2020-01-08 9:46 Rudi Blom 2020-01-08 14:15 ` Chet Ramey 2020-01-08 15:11 ` Nemo Nusquam 0 siblings, 2 replies; 118+ messages in thread From: Rudi Blom @ 2020-01-08 9:46 UTC (permalink / raw) To: tuhs; +Cc: doug >Date: Tue, 07 Jan 2020 14:57:40 -0500. >From: Doug McIlroy <> >To: tuhs@tuhs.org, thomas.paulsen@firemail.de >Subject: Re: [TUHS] screen editors >Message-ID: <202001071957.007JveQu169574@coolidge.cs.dartmouth.edu> >Content-Type: text/plain; charset=us-ascii .. snip .. >% wc -c /bin/vi bin/sam bin/samterm >1706152 /bin/vi > 112208 bin/sam > 153624 bin/samterm >These mumbers are from Red Hat Linux. >The 6:1 discrepancy is understated because >vi is stripped and the sam files are not. >All are 64-bit, dynamically linked. That's a real big vi in RHL. Looking at a few (commercial) unixes I get SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi - /usr/bin/vi: iAPX 386 executable Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi - /usr/bin/vi: COFF format alpha dynamically linked, demand paged sticky executable or object module stripped - version 3.13-14 HP-UX 11.31 748996 Aug 28 2009 /bin/vi -- /bin/vi: ELF-32 executable object file - IA64 ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 9:46 Rudi Blom @ 2020-01-08 14:15 ` Chet Ramey 2020-01-08 15:15 ` Steffen Nurpmeso 2020-01-08 23:21 ` Dave Horsfall 2020-01-08 15:11 ` Nemo Nusquam 1 sibling, 2 replies; 118+ messages in thread From: Chet Ramey @ 2020-01-08 14:15 UTC (permalink / raw) To: Rudi Blom, tuhs; +Cc: doug On 1/8/20 4:46 AM, Rudi Blom wrote: > That's a real big vi in RHL. It's vim. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 14:15 ` Chet Ramey @ 2020-01-08 15:15 ` Steffen Nurpmeso 2020-01-08 15:42 ` Steve Mynott [not found] ` <68b3d6df-94f6-625d-39bf-6149b4c177c9@andrewnesbit.org> 2020-01-08 23:21 ` Dave Horsfall 1 sibling, 2 replies; 118+ messages in thread From: Steffen Nurpmeso @ 2020-01-08 15:15 UTC (permalink / raw) To: Chet Ramey; +Cc: tuhs, Rudi Blom, doug Chet Ramey wrote in <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>: |On 1/8/20 4:46 AM, Rudi Blom wrote: |> That's a real big vi in RHL. | |It's vim. It is a tremendous effort of Bram Moolenaar and the vim contributors to maintain this codebase that can be configured in uncountable ways, just looking at the pre-configured feature sets that exist lead to tiny, small, normal, big and huge. As far as i know it has real support for languages of the world, which is a different thing than being UTF-8 all through the engine. (But i think emacs is better here, i see one markable emacs developer taking care on the Unicode list, regarding real BiDi support, for example.) With all my sympathy for pico at first and for long, then mg / ee / nano / jupp etc., and with my repeated tries to switch over to vile, in the last two decades i always came back home to vim, for the one thing or the other. Two endless loops in all this time. I only use the smallest thinkable subsets of features, though. (Only lumberjack-style editing here, anyway.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 15:15 ` Steffen Nurpmeso @ 2020-01-08 15:42 ` Steve Mynott [not found] ` <68b3d6df-94f6-625d-39bf-6149b4c177c9@andrewnesbit.org> 1 sibling, 0 replies; 118+ messages in thread From: Steve Mynott @ 2020-01-08 15:42 UTC (permalink / raw) To: tuhs On 08/01/2020, Steffen Nurpmeso <steffen@sdaoden.eu> wrote: > It is a tremendous effort of Bram Moolenaar and the vim > contributors to maintain this codebase that can be configured in > uncountable ways, just looking at the pre-configured feature sets > that exist lead to tiny, small, normal, big and huge. Indeed. It's larger because it does a lot more! Small isn't necessarily beautiful and all those tiny old vendor vi binaries are probably full of bugs since they were never actively maintained. The last time I used Solaris vi it didn't handle long lines properly and the more recent classic Joy vi open source forks are full of bug fixes (often for quite serious problems). If you want a tiny vi compile one of those up or use nvi. If you want features use vim. -- Steve Mynott <steve.mynott@gmail.com> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 ^ permalink raw reply [flat|nested] 118+ messages in thread
[parent not found: <68b3d6df-94f6-625d-39bf-6149b4c177c9@andrewnesbit.org>]
* Re: [TUHS] screen editors [not found] ` <68b3d6df-94f6-625d-39bf-6149b4c177c9@andrewnesbit.org> @ 2020-01-08 20:56 ` Steffen Nurpmeso 0 siblings, 0 replies; 118+ messages in thread From: Steffen Nurpmeso @ 2020-01-08 20:56 UTC (permalink / raw) To: U'll Be King of the Stars; +Cc: tuhs U'll Be King of the Stars wrote in <68b3d6df-94f6-625d-39bf-6149b4c177c9\ @andrewnesbit.org>: |On 08/01/2020 15:15, Steffen Nurpmeso wrote: |> (But i think emacs is better here, i see one markable |> emacs developer taking care on the Unicode list, regarding real |> BiDi support, for example.) | |I have been following the emacs-devel mailing list out of interest for |many years. From this, I think the person you are referring to in your |comment, is Eli Zaretskii. Is that right? Yep. Then again i have to say it was a lot of a mistake, because the OSS man who i referred to and who is known for questions deep in the material is indeed Karl Williamson of i think Perl. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 14:15 ` Chet Ramey 2020-01-08 15:15 ` Steffen Nurpmeso @ 2020-01-08 23:21 ` Dave Horsfall 2020-01-09 0:08 ` Warner Losh 1 sibling, 1 reply; 118+ messages in thread From: Dave Horsfall @ 2020-01-08 23:21 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Wed, 8 Jan 2020, Chet Ramey wrote: >> That's a real big vi in RHL. > > It's vim. It's also VIM on the Mac. -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 23:21 ` Dave Horsfall @ 2020-01-09 0:08 ` Warner Losh 2020-01-09 1:28 ` Larry McVoy 2020-01-09 9:05 ` Thomas Paulsen 0 siblings, 2 replies; 118+ messages in thread From: Warner Losh @ 2020-01-09 0:08 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 299 bytes --] On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall <dave@horsfall.org> wrote: > On Wed, 8 Jan 2020, Chet Ramey wrote: > > >> That's a real big vi in RHL. > > > > It's vim. > > It's also VIM on the Mac. > Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD default for vi. Warner > [-- Attachment #2: Type: text/html, Size: 884 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 0:08 ` Warner Losh @ 2020-01-09 1:28 ` Larry McVoy 2020-01-09 1:40 ` Bakul Shah 2020-01-09 2:14 ` Greg 'groggy' Lehey 2020-01-09 9:05 ` Thomas Paulsen 1 sibling, 2 replies; 118+ messages in thread From: Larry McVoy @ 2020-01-09 1:28 UTC (permalink / raw) To: Warner Losh; +Cc: The Eunuchs Hysterical Society On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote: > On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall <dave@horsfall.org> wrote: > > > On Wed, 8 Jan 2020, Chet Ramey wrote: > > > > >> That's a real big vi in RHL. > > > > > > It's vim. > > > > It's also VIM on the Mac. > > > > Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD > default for vi. I was gonna stay out of this thread (it has the feel of old folks somehow) but 2 comments: Keith did nvi (I can't remember why? licensing or something) and he did a pretty faithful bug for bug compatible job. I've always wondered why. I like Keith but it seemed like a waste. There were other people taking vi forward, elvis, xvi (I hacked the crap out of that one, made it mmap the file and had a whole string library that treated \n like NULL) and I think vim was coming along. So doing a compat vi felt like a step backward for me. For all the vim haters, come on. Vim is awesome, it gave me the one thing that I wanted from emacs, multiple windows. I use that all the time. It's got piles of stuff that I don't use, probably should, but it is every bit as good of a vi as the original and then it added more. I'm super grateful that vim came along. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 1:28 ` Larry McVoy @ 2020-01-09 1:40 ` Bakul Shah 2020-01-09 2:04 ` Clem Cole 2020-01-09 2:14 ` Greg 'groggy' Lehey 1 sibling, 1 reply; 118+ messages in thread From: Bakul Shah @ 2020-01-09 1:40 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society On Jan 8, 2020, at 5:28 PM, Larry McVoy <lm@mcvoy.com> wrote: > > On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote: >> On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall <dave@horsfall.org> wrote: >> >>> On Wed, 8 Jan 2020, Chet Ramey wrote: >>> >>>>> That's a real big vi in RHL. >>>> >>>> It's vim. >>> >>> It's also VIM on the Mac. >>> >> >> Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD >> default for vi. > > I was gonna stay out of this thread (it has the feel of old folks somehow) > but 2 comments: > > Keith did nvi (I can't remember why? licensing or something) and he did > a pretty faithful bug for bug compatible job. I've always wondered why. > I like Keith but it seemed like a waste. There were other people taking > vi forward, elvis, xvi (I hacked the crap out of that one, made it mmap > the file and had a whole string library that treated \n like NULL) and > I think vim was coming along. So doing a compat vi felt like a step > backward for me. > > For all the vim haters, come on. Vim is awesome, it gave me the one > thing that I wanted from emacs, multiple windows. I use that all the > time. It's got piles of stuff that I don't use, probably should, but > it is every bit as good of a vi as the original and then it added more. > I'm super grateful that vim came along. The first thing I do on a new machine is to install nvi. Very grateful to Keith Bostic for implementing it. I do use multiple windows — only horizontal splits but that is good enough for me as all my terminal windows are 80 chars wide. Not a vim hater but never saw the need. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 1:40 ` Bakul Shah @ 2020-01-09 2:04 ` Clem Cole 2020-01-09 2:07 ` Larry McVoy 0 siblings, 1 reply; 118+ messages in thread From: Clem Cole @ 2020-01-09 2:04 UTC (permalink / raw) To: Bakul Shah; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 765 bytes --] On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote: > The first thing I do on a new machine is to install nvi. Very grateful to > Keith Bostic for implementing it. I do use multiple windows — only > horizontal splits but that is good enough for me as all my terminal > windows are 80 chars wide. Not a vim hater but never saw the need. I pretty much do the same thing. I think what I hate about vim is that it's almost, vi but not the same. My fingers screw up when I use it. For instance, he 'fixed' undo. I guess I learned my lesson from my time at UCB. Henry Spencer once said, "BSD 4.2 is just like UNIX, only different." I rather see something new and completely different than changing behavior that people rely upon. [-- Attachment #2: Type: text/html, Size: 1432 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 2:04 ` Clem Cole @ 2020-01-09 2:07 ` Larry McVoy 2020-01-09 2:12 ` Clem Cole 0 siblings, 1 reply; 118+ messages in thread From: Larry McVoy @ 2020-01-09 2:07 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote: > > > The first thing I do on a new machine is to install nvi. Very grateful to > > Keith Bostic for implementing it. I do use multiple windows ??? only > > horizontal splits but that is good enough for me as all my terminal > > windows are 80 chars wide. Not a vim hater but never saw the need. > > I pretty much do the same thing. I think what I hate about vim is that it's > almost, vi but not the same. My fingers screw up when I use it. For > instance, he 'fixed' undo. Holy crap Clem, you need to embrace that. His undo goes back forever. And you can undo the undo and go forward forever. Not liking that puts you in the "get off my lawn" old guy camp. Which is fine if that's who you want to be (sometimes I'm that guy). ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 2:07 ` Larry McVoy @ 2020-01-09 2:12 ` Clem Cole 2020-01-09 2:59 ` Bakul Shah ` (2 more replies) 0 siblings, 3 replies; 118+ messages in thread From: Clem Cole @ 2020-01-09 2:12 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1161 bytes --] make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. and my lawn was lush and green before the snow came ;-) On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote: > On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: > > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote: > > > > > The first thing I do on a new machine is to install nvi. Very grateful > to > > > Keith Bostic for implementing it. I do use multiple windows ??? only > > > horizontal splits but that is good enough for me as all my terminal > > > windows are 80 chars wide. Not a vim hater but never saw the need. > > > > I pretty much do the same thing. I think what I hate about vim is that > it's > > almost, vi but not the same. My fingers screw up when I use it. For > > instance, he 'fixed' undo. > > Holy crap Clem, you need to embrace that. His undo goes back forever. > And you can undo the undo and go forward forever. > > Not liking that puts you in the "get off my lawn" old guy camp. Which > is fine if that's who you want to be (sometimes I'm that guy). > [-- Attachment #2: Type: text/html, Size: 1962 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 2:12 ` Clem Cole @ 2020-01-09 2:59 ` Bakul Shah 2020-01-09 3:08 ` Larry McVoy 2020-01-09 3:27 ` Mary Ann Horton 2020-01-09 4:23 ` Jon Steinhart 2 siblings, 1 reply; 118+ messages in thread From: Bakul Shah @ 2020-01-09 2:59 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society Early in vim’s life I had emailed Moolenaar asking him if he would be willing to add an option for nvi like behavior for undo/redo. He wasn’t interested so I lost interest. nvi’s u & . behavior is not only quite clever but also much more intuitive and you don’t have to press the ctl key! > On Jan 8, 2020, at 6:12 PM, Clem Cole <clemc@ccc.com> wrote: > > make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. > and my lawn was lush and green before the snow came ;-) > > > > On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote: > On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: > > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote: > > > > > The first thing I do on a new machine is to install nvi. Very grateful to > > > Keith Bostic for implementing it. I do use multiple windows ??? only > > > horizontal splits but that is good enough for me as all my terminal > > > windows are 80 chars wide. Not a vim hater but never saw the need. > > > > I pretty much do the same thing. I think what I hate about vim is that it's > > almost, vi but not the same. My fingers screw up when I use it. For > > instance, he 'fixed' undo. > > Holy crap Clem, you need to embrace that. His undo goes back forever. > And you can undo the undo and go forward forever. > > Not liking that puts you in the "get off my lawn" old guy camp. Which > is fine if that's who you want to be (sometimes I'm that guy). ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 2:59 ` Bakul Shah @ 2020-01-09 3:08 ` Larry McVoy 2020-01-09 3:43 ` Bakul Shah 0 siblings, 1 reply; 118+ messages in thread From: Larry McVoy @ 2020-01-09 3:08 UTC (permalink / raw) To: Bakul Shah; +Cc: The Eunuchs Hysterical Society I feel like there is an option to get nvi behaviour now but I dunno why you want that. Are you seriously advocating for less? Because objectively vim gives you more. And it is faithful to vi, it has all the buffers so you can put stuff back that way. Maybe I'm clueless or I drank the koolaid, but I love vim. It's vi but better. On Wed, Jan 08, 2020 at 06:59:02PM -0800, Bakul Shah wrote: > Early in vim???s life I had emailed Moolenaar asking him if he would be > willing to add an option for nvi like behavior for undo/redo. He wasn???t > interested so I lost interest. nvi???s u & . behavior is not only quite clever > but also much more intuitive and you don???t have to press the ctl key! > > > On Jan 8, 2020, at 6:12 PM, Clem Cole <clemc@ccc.com> wrote: > > > > make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. > > and my lawn was lush and green before the snow came ;-) > > > > > > > > On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote: > > On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: > > > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote: > > > > > > > The first thing I do on a new machine is to install nvi. Very grateful to > > > > Keith Bostic for implementing it. I do use multiple windows ??? only > > > > horizontal splits but that is good enough for me as all my terminal > > > > windows are 80 chars wide. Not a vim hater but never saw the need. > > > > > > I pretty much do the same thing. I think what I hate about vim is that it's > > > almost, vi but not the same. My fingers screw up when I use it. For > > > instance, he 'fixed' undo. > > > > Holy crap Clem, you need to embrace that. His undo goes back forever. > > And you can undo the undo and go forward forever. > > > > Not liking that puts you in the "get off my lawn" old guy camp. Which > > is fine if that's who you want to be (sometimes I'm that guy). -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 3:08 ` Larry McVoy @ 2020-01-09 3:43 ` Bakul Shah 0 siblings, 0 replies; 118+ messages in thread From: Bakul Shah @ 2020-01-09 3:43 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society If this option was added back then (992-94) I might have switched over. I think I was tempted as it was “programmable”. But as it didn’t have any other new features that I really wanted plus I was always messing up undo/redo, probably like Clem, there was not much point in switching. As it happens, I didn’t use the programmability feature even when it was added to nvi! No point in advocating as anyone who is used to the “more” of vim would be frustrated with nvi! > On Jan 8, 2020, at 7:08 PM, Larry McVoy <lm@mcvoy.com> wrote: > > I feel like there is an option to get nvi behaviour now but I dunno > why you want that. Are you seriously advocating for less? Because > objectively vim gives you more. > > And it is faithful to vi, it has all the buffers so you can put stuff > back that way. > > Maybe I'm clueless or I drank the koolaid, but I love vim. It's vi > but better. > > On Wed, Jan 08, 2020 at 06:59:02PM -0800, Bakul Shah wrote: >> Early in vim???s life I had emailed Moolenaar asking him if he would be >> willing to add an option for nvi like behavior for undo/redo. He wasn???t >> interested so I lost interest. nvi???s u & . behavior is not only quite clever >> but also much more intuitive and you don???t have to press the ctl key! >> >>> On Jan 8, 2020, at 6:12 PM, Clem Cole <clemc@ccc.com> wrote: >>> >>> make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. >>> and my lawn was lush and green before the snow came ;-) >>> >>> >>> >>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote: >>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: >>>> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote: >>>> >>>>> The first thing I do on a new machine is to install nvi. Very grateful to >>>>> Keith Bostic for implementing it. I do use multiple windows ??? only >>>>> horizontal splits but that is good enough for me as all my terminal >>>>> windows are 80 chars wide. Not a vim hater but never saw the need. >>>> >>>> I pretty much do the same thing. I think what I hate about vim is that it's >>>> almost, vi but not the same. My fingers screw up when I use it. For >>>> instance, he 'fixed' undo. >>> >>> Holy crap Clem, you need to embrace that. His undo goes back forever. >>> And you can undo the undo and go forward forever. >>> >>> Not liking that puts you in the "get off my lawn" old guy camp. Which >>> is fine if that's who you want to be (sometimes I'm that guy). > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 2:12 ` Clem Cole 2020-01-09 2:59 ` Bakul Shah @ 2020-01-09 3:27 ` Mary Ann Horton 2020-01-09 3:34 ` Larry McVoy 2020-01-09 3:49 ` Bakul Shah 2020-01-09 4:23 ` Jon Steinhart 2 siblings, 2 replies; 118+ messages in thread From: Mary Ann Horton @ 2020-01-09 3:27 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 1778 bytes --] vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity. Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often. Mary Ann On 1/8/20 6:12 PM, Clem Cole wrote: > make a new command, don't break the old one.... maybe offer a way to > map the new one over the old -- but don't make it the default. > and my lawn was lush and green before the snow came ;-) > > > > On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com > <mailto:lm@mcvoy.com>> wrote: > > On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: > > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com > <mailto:bakul@bitblocks.com>> wrote: > > > > > The first thing I do on a new machine is to install nvi. Very > grateful to > > > Keith Bostic for implementing it. I do use multiple windows > ??? only > > > horizontal splits but that is good enough for me as all my > terminal > > > windows are 80 chars wide. Not a vim hater but never saw the need. > > > > I pretty much do the same thing. I think what I hate about vim > is that it's > > almost, vi but not the same. My fingers screw up when I use it. For > > instance, he 'fixed' undo. > > Holy crap Clem, you need to embrace that. His undo goes back forever. > And you can undo the undo and go forward forever. > > Not liking that puts you in the "get off my lawn" old guy camp. Which > is fine if that's who you want to be (sometimes I'm that guy). > [-- Attachment #2: Type: text/html, Size: 3388 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 3:27 ` Mary Ann Horton @ 2020-01-09 3:34 ` Larry McVoy 2020-01-09 3:49 ` Bakul Shah 1 sibling, 0 replies; 118+ messages in thread From: Larry McVoy @ 2020-01-09 3:34 UTC (permalink / raw) To: Mary Ann Horton; +Cc: tuhs +1 On Wed, Jan 08, 2020 at 07:27:13PM -0800, Mary Ann Horton wrote: > vim has an option to undo the vi way. "set cpoptions=u". There is a full set > of vi-compatible options if you want them. "set cp" turns on full vi > compatiblity. > > Funny, I see vim as the vi that comes with UNIX, and never learned the > enhancements, but I just tried it out and I don't have the compatibility > option set. I don't seem to have noticed. I guess I don't do the "undo > toggle" all that often. > > ?????? Mary Ann > > On 1/8/20 6:12 PM, Clem Cole wrote: > >make a new command, don't break the old one....?? maybe offer a way to map > >the new one over the old -- but don't make it the default. > >and my lawn was lush and green before the snow came ;-) > > > > > > > >On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com > ><mailto:lm@mcvoy.com>> wrote: > > > > On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: > > > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com > > <mailto:bakul@bitblocks.com>> wrote: > > > > > > > The first thing I do on a new machine is to install nvi. Very > > grateful to > > > > Keith Bostic for implementing it. I do use multiple windows > > ??? only > > > > horizontal splits but that is good enough for me as all my > > terminal > > > > windows are 80 chars wide. Not a vim hater but never saw the need. > > > > > > I pretty much do the same thing. I think what I hate about vim > > is that it's > > > almost, vi but not the same. My fingers screw up when I use it.?? For > > > instance, he 'fixed' undo. > > > > Holy crap Clem, you need to embrace that.?? His undo goes back forever. > > And you can undo the undo and go forward forever. > > > > Not liking that puts you in the "get off my lawn" old guy camp.?? Which > > is fine if that's who you want to be (sometimes I'm that guy). > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 3:27 ` Mary Ann Horton 2020-01-09 3:34 ` Larry McVoy @ 2020-01-09 3:49 ` Bakul Shah 2020-01-09 3:55 ` Mary Ann Horton 1 sibling, 1 reply; 118+ messages in thread From: Bakul Shah @ 2020-01-09 3:49 UTC (permalink / raw) To: Mary Ann Horton; +Cc: tuhs It doesn’t work the same way. I just tried it (vim-8.0.something). The way it is supposed to work is this: the first u undoes the last change. Then you keep hitting . to keep undoing more. Then if you went back too far, you hit u again, to undo the undo and further . will keep redoing. You can go back and forth this way as many times as you wish. > On Jan 8, 2020, at 7:27 PM, Mary Ann Horton <mah@mhorton.net> wrote: > > vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity. > Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often. > > Mary Ann > On 1/8/20 6:12 PM, Clem Cole wrote: >> make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. >> and my lawn was lush and green before the snow came ;-) >> >> >> >> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote: >> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: >> > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote: >> > >> > > The first thing I do on a new machine is to install nvi. Very grateful to >> > > Keith Bostic for implementing it. I do use multiple windows ??? only >> > > horizontal splits but that is good enough for me as all my terminal >> > > windows are 80 chars wide. Not a vim hater but never saw the need. >> > >> > I pretty much do the same thing. I think what I hate about vim is that it's >> > almost, vi but not the same. My fingers screw up when I use it. For >> > instance, he 'fixed' undo. >> >> Holy crap Clem, you need to embrace that. His undo goes back forever. >> And you can undo the undo and go forward forever. >> >> Not liking that puts you in the "get off my lawn" old guy camp. Which >> is fine if that's who you want to be (sometimes I'm that guy). ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 3:49 ` Bakul Shah @ 2020-01-09 3:55 ` Mary Ann Horton 2020-01-09 5:27 ` Bakul Shah 0 siblings, 1 reply; 118+ messages in thread From: Mary Ann Horton @ 2020-01-09 3:55 UTC (permalink / raw) To: Bakul Shah; +Cc: tuhs Are you referring to the special case where an undo of "p" (put) will sucessively re-insert the most recent things you've deleted? I just tried that in vim and it didn't seem to support the special case the way vi did. Mary Ann On 1/8/20 7:49 PM, Bakul Shah wrote: > It doesn’t work the same way. I just tried it (vim-8.0.something). > The way it is supposed to work is this: the first u undoes the last change. > Then you keep hitting . to keep undoing more. Then if you went back too far, > you hit u again, to undo the undo and further . will keep redoing. You can > go back and forth this way as many times as you wish. > >> On Jan 8, 2020, at 7:27 PM, Mary Ann Horton <mah@mhorton.net> wrote: >> >> vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity. >> Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often. >> >> Mary Ann >> On 1/8/20 6:12 PM, Clem Cole wrote: >>> make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. >>> and my lawn was lush and green before the snow came ;-) >>> >>> >>> >>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote: >>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: >>>> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote: >>>> >>>>> The first thing I do on a new machine is to install nvi. Very grateful to >>>>> Keith Bostic for implementing it. I do use multiple windows ??? only >>>>> horizontal splits but that is good enough for me as all my terminal >>>>> windows are 80 chars wide. Not a vim hater but never saw the need. >>>> I pretty much do the same thing. I think what I hate about vim is that it's >>>> almost, vi but not the same. My fingers screw up when I use it. For >>>> instance, he 'fixed' undo. >>> Holy crap Clem, you need to embrace that. His undo goes back forever. >>> And you can undo the undo and go forward forever. >>> >>> Not liking that puts you in the "get off my lawn" old guy camp. Which >>> is fine if that's who you want to be (sometimes I'm that guy). ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 3:55 ` Mary Ann Horton @ 2020-01-09 5:27 ` Bakul Shah 0 siblings, 0 replies; 118+ messages in thread From: Bakul Shah @ 2020-01-09 5:27 UTC (permalink / raw) To: Mary Ann Horton; +Cc: tuhs Short answer: there is no special case in nvi. P or p put back the contents of the last delete. u undoes whatever was the last change (including the last undo or redo). . repeats whatever was the last modifying command. A detailed answer would merely confuse you. At least my attempt at it! Suggest you try out various combinations in nvi and compare with vim. > On Jan 8, 2020, at 7:55 PM, Mary Ann Horton <mah@mhorton.net> wrote: > > Are you referring to the special case where an undo of "p" (put) will sucessively re-insert the most recent things you've deleted? > > I just tried that in vim and it didn't seem to support the special case the way vi did. > > Mary Ann > > On 1/8/20 7:49 PM, Bakul Shah wrote: >> It doesn’t work the same way. I just tried it (vim-8.0.something). >> The way it is supposed to work is this: the first u undoes the last change. >> Then you keep hitting . to keep undoing more. Then if you went back too far, >> you hit u again, to undo the undo and further . will keep redoing. You can >> go back and forth this way as many times as you wish. >> >>> On Jan 8, 2020, at 7:27 PM, Mary Ann Horton <mah@mhorton.net> wrote: >>> >>> vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity. >>> Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often. >>> >>> Mary Ann >>> On 1/8/20 6:12 PM, Clem Cole wrote: >>>> make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. >>>> and my lawn was lush and green before the snow came ;-) >>>> >>>> >>>> >>>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote: >>>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: >>>>> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote: >>>>> >>>>>> The first thing I do on a new machine is to install nvi. Very grateful to >>>>>> Keith Bostic for implementing it. I do use multiple windows ??? only >>>>>> horizontal splits but that is good enough for me as all my terminal >>>>>> windows are 80 chars wide. Not a vim hater but never saw the need. >>>>> I pretty much do the same thing. I think what I hate about vim is that it's >>>>> almost, vi but not the same. My fingers screw up when I use it. For >>>>> instance, he 'fixed' undo. >>>> Holy crap Clem, you need to embrace that. His undo goes back forever. >>>> And you can undo the undo and go forward forever. >>>> >>>> Not liking that puts you in the "get off my lawn" old guy camp. Which >>>> is fine if that's who you want to be (sometimes I'm that guy). ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 2:12 ` Clem Cole 2020-01-09 2:59 ` Bakul Shah 2020-01-09 3:27 ` Mary Ann Horton @ 2020-01-09 4:23 ` Jon Steinhart 2020-01-09 15:54 ` Clem Cole 2020-01-18 2:06 ` Michael Parson 2 siblings, 2 replies; 118+ messages in thread From: Jon Steinhart @ 2020-01-09 4:23 UTC (permalink / raw) To: The Eunuchs Hysterical Society Clem Cole writes: > > make a new command, don't break the old one.... maybe offer a way to map > the new one over the old -- but don't make it the default. > and my lawn was lush and green before the snow came ;-) Clem, this seems like an unusual position for you to take. vim is backwards compatible with vi (and also ed), so it added to an existing ecosystem. Jon ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 4:23 ` Jon Steinhart @ 2020-01-09 15:54 ` Clem Cole 2020-01-09 17:21 ` Jon Steinhart ` (2 more replies) 2020-01-18 2:06 ` Michael Parson 1 sibling, 3 replies; 118+ messages in thread From: Clem Cole @ 2020-01-09 15:54 UTC (permalink / raw) To: Jon Steinhart Cc: The Eunuchs Hysterical Society, Computer Old Farts Followers [-- Attachment #1: Type: text/plain, Size: 7167 bytes --] Answering, but CCing COFF if folks want to continue. This is less about UNIX and more about how we all got to where we are. On Wed, Jan 8, 2020 at 11:24 PM Jon Steinhart <jon@fourwinds.com> wrote: > Clem, this seems like an unusual position for you to take. vim is > backwards > compatible with vi (and also ed), so it added to an existing ecosystem. > No, really unusually when you think about it. vim is backward compatible except when it's not (as Bakul points out) - which is my complaint. It's *almost* compatible and those small differences are really annoying when you expect one thing and get something else (*i.e.* the least astonishment principle). The key point here is for *some people*, those few differences are not an issue and are not astonished by them. But for *some of the rest of us* (probably people like me that have used the program since PDP-11 days) that only really care about the original parts, the new stuff is of little value and so the small differences are astonishing. Which comes back to the question of good and best. It all depends on one what you value/where you put the high order bit. I'm not willing to "pay" for the it; as it gives me little value. Doug started this thread with his observation that ex/vi was huge compared to other editors. * i.e.* value: small simple easy to understand (Rob's old "*cat -v considered harmful*" argument if you will). The BSD argument had always been: "the new stuff is handy." The emacs crew tends to take a similar stand. I probably don't go quite as far as Rob, but I certainly lean in that direction. I generally would rather something small and new that solves a different (set of) problem(s), then adding yet another wart on to an older program, *particularly when you change the base functionality *- which is my vi *vs. *vim complaint*.* [i.e. 'partial credit' does not cut it]. To me, another good example is 'more', 'less' and 'pg'. Eric Schienbrood wrote the original more(ucb) to try to duplicate the ITS functionality (he wrote it for the PDP-11/70 in Cory Hall BTW - Ernie did not exist and 4.1BSD was a few years in the future - so small an simple of a huge value). It went out in the BSD tapes, people loved it and were happy. It solved a problem as we had it. Life was good. Frankly, other than NIH, I'm not sure why the folks at AT&T decided to create pg a few years later since more was already in the wild, but at least it was a different program (Mary Ann's story of vi *vs*. se if probably in the same vein). But because of that behavior, if someone like me came to an AT&T based system with only pg installed, so those of us that liked/were used to more(ucb) could install it and life was good. Note pg was/is different in functionality, it's similar, but not finger compatible. But other folks seem to have thought neither was 'good enough' -- thus later less(gnu) was created adding a ton of new functionality to Eric's program. The facts are clear, some (ney many) people >>love<< that new functionality, like going backward. I >>personally<< rarely care/need for it, Eric's program was (is) good enough for me. Like Doug's observation of ed *vs.* ex/vi; less is huge compared to the original more (or pg for that matter). But if you value the new features, I suspect you might think that's not an issue. Thanks to Moore's law, the size in this case probably does not matter too much (other than introducing new bugs). At least, when folks wrote did Gnu's less, the basic more(ucb) behavior was left along and if you set PAGER=more less(gnu) pretty much works as I expect it too. So I now don't bring Eric's program with me, the same way Bakul describes installing nvi on new systems (an activiity I also do). Back to vi *vs.* nvi *vs.* vim *et. al.* Frankly, in my own case, I do >>occaisonally<< use split screens, but frankly, I can get most of the same from having a window manager, different iterm2 windows and cut/paste. So even that extension to nvi, is of limited value to me. vim just keeps adding more and more cruft and its even bigger. I personally don't care for the new functionality, and the size of it all is worrisome. What am I buying? That said, if the new features do not hurt me, then I don't really care. I might even use some of the new functionality - hey I run mac OS not v7 or BSD 4.x for my day to day work and I do use the mac window manager, the browser *et al*, but as I type this message I have 6 other iterm2 windows open with work I am doing in other areas. Let me take a look at this issue in a different way. I have long been a 'car guy' and like many of those times in my youth spent time and money playing/racing etc. I've always thought electric was a great idea/but there has been nothing for me. Note: As many of you know my work in computers has been in HPC, and I've been lucky to spend a lot of time with my customers, in the auto and aerospace industry (*i.e.* the current Audi A6 was designed on one of my supercomputer systems). The key point is have tended to follow technology in their area and tend to "in-tune" with a lot of developments. The result, except for my wife's minivan (that she preferred in the years when our kids were small), I've always been a die-hard German-engineered/performance car person. But when Elon announced the Model 3 (like 1/2 the techie world), I put down a deposit and waited. Well why I was waiting, my techie daughter (who also loves cars), got a chance to drive one. She predicted I would hate it!!! So when my ticket finally came up, I went to drive them. She was right!!! With the Model 3, you get a cool car, but it's about the size of a Corrolla. Coming from Germans cars for the last 35 years, the concept of spending $60K US in practice for a Corrolla just did not do it for me. I ended up ordering the current Unixmobile, my beloved Tesla Model S/P100D. The truth is, I paid a lot of money for it but I *value *what I got for my money. A number of people don't think it's worth it. I get that, but I'm still happy with what I have. Will there someday be a $20K electric car like my Model S? While I think electric cars will get there (I point out the same price curve on technology such microwave ovens from the 1970so today), but I actually doubt that there will be a $20K electric vehicle like my Model S. The reason is that to sell this car because it as to be expensive for technology-based reasons, so Tesla had to add a lot of 'luxury' features like other cars in the class, other sports cars, Mercedes, *et al*. As they removed them (*i.e.* the Model 3) you still get a cool car, but it's not at all the same as the Model S. So the point is, if I wanted an electric car, I had to choose between a performance/luxury *vs*. size/functionality. I realized I valued the former (and still do), but I understand not everyone does or will. Coming back to our topic, I really don't think this is a 'get my lawn' issue as much, as asking someone what they really value/what they really need. If you place a high-value you something, you will argue that its best; if it has little value you will not. [-- Attachment #2: Type: text/html, Size: 11739 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 15:54 ` Clem Cole @ 2020-01-09 17:21 ` Jon Steinhart 2020-01-09 17:30 ` Warner Losh ` (2 more replies) 2020-01-09 19:02 ` Steffen Nurpmeso 2020-01-09 20:20 ` Mary Ann Horton 2 siblings, 3 replies; 118+ messages in thread From: Jon Steinhart @ 2020-01-09 17:21 UTC (permalink / raw) To: The Eunuchs Hysterical Society Clem Cole writes: > > Answering, but CCing COFF if folks want to continue. This is less about > UNIX and more about how we all got to where we are. > > On Wed, Jan 8, 2020 at 11:24 PM Jon Steinhart <jon@fourwinds.com> wrote: > > > Clem, this seems like an unusual position for you to take. vim is > > backwards > > compatible with vi (and also ed), so it added to an existing ecosystem. > > > No, really unusually when you think about it. vim is backward compatible > except when it's not (as Bakul points out) - which is my complaint. It's > *almost* compatible and those small differences are really annoying when > you expect one thing and get something else (*i.e.* the least astonishment > principle). > > ... OK, ok, the point that it's not 100% compatible wins the day. Couple more points and then it's time to move on. While I spend a lot of time railing against bad programming, the fact that vim is huge doesn't bother me too much because my machine has more memory that the machine on which I started using vi had disk. And just because it still blows my mind, my machine (on just one of the drives) has more disk than was available in the world when I started using vi. Good chance that my CPU has more cache memory than the PDP-11/70 on which I started using vi had main memory. So the size doesn't matter too much for me. One of the reasons that I chose vi over emacs was architectural. At a certain level, vi was a text editor and emacs was an operating system, and since I was running UNIX and was a UNIX philosophy person I just didn't want to be running an operating system on top of an operating system just to do text editing. It's for that reason that I hate the addition of multiple windows to vi. I already have a windowing system on my machine, and that's what I use for windows. To me, the correct thing to do is to open a new desktop window to edit a new file and start a new instance of vi, not to use vi to open another internal window. I guess that what I'm saying is that I think that rather than following the UNIX philosophy of having distinct tools and composing, much modern software tries to do too much stuff that's not unique to its domain. A strained analogy would be if every "little language" felt that it had to re-implement a big language too. Jon ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 17:21 ` Jon Steinhart @ 2020-01-09 17:30 ` Warner Losh 2020-01-09 17:56 ` Bakul Shah 2020-01-09 18:53 ` Larry McVoy 2 siblings, 0 replies; 118+ messages in thread From: Warner Losh @ 2020-01-09 17:30 UTC (permalink / raw) To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 873 bytes --] On Thu, Jan 9, 2020 at 10:22 AM Jon Steinhart <jon@fourwinds.com> wrote: > One of the reasons that I chose vi over emacs was architectural. At a > certain > level, vi was a text editor and emacs was an operating system, and since I > was > running UNIX and was a UNIX philosophy person I just didn't want to be > running > an operating system on top of an operating system just to do text editing. > I chose emacs because of muscle memory (Both the VAX and TOPS-20 machines at school had emacs as the default editor) and also because it lets me program better. I didn't let the fact it accomplished that by trying to be an OS or LISP-M or whatever get in the way of using the best tool for the job. In the 90s this meant that I had to be careful about the machines I used it on. These days, it just doesn't matter. Mostly, though, it was finger muscle memory :) Warner [-- Attachment #2: Type: text/html, Size: 1240 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 17:21 ` Jon Steinhart 2020-01-09 17:30 ` Warner Losh @ 2020-01-09 17:56 ` Bakul Shah 2020-01-18 2:11 ` Michael Parson 2020-01-09 18:53 ` Larry McVoy 2 siblings, 1 reply; 118+ messages in thread From: Bakul Shah @ 2020-01-09 17:56 UTC (permalink / raw) To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society On Jan 9, 2020, at 9:21 AM, Jon Steinhart <jon@fourwinds.com> wrote: > > It's for that reason that I hate the addition of multiple windows to vi. I > already have a windowing system on my machine, and that's what I use for windows. > To me, the correct thing to do is to open a new desktop window to edit a new file > and start a new instance of vi, not to use vi to open another internal window. The Rand editor made good use of multiple windows. You could set things up so that two windows would scroll *in sync*. This is handy e.g. when you are looking at two columns or rows that far apart in the same file or in different files and too large so you need to scroll. Acme makes even better use of multiple windows. Right click on a compile error message in one window and the cursor moves the error causing line in the source file in another window etc. You can repeat as many times as you want. So I tend to think combining multiple windows and editing can be effective. > I guess that what I'm saying is that I think that rather than following the > UNIX philosophy of having distinct tools and composing, much modern software tries > to do too much stuff that's not unique to its domain. A strained analogy would be > if every "little language" felt that it had to re-implement a big language too. Finding the "right cut" of functionality is not easy. Scheme or Common Lisp? Editors and a set of tools or an all singing all dancing IDE? Can one implement something like Photoshop as a set of separate tools that can be combined any way? What old style Unix tools give you is isolation and (one way) controlled communication. Can this model be generalized to a set of Lego blocks out of which one can compose even complex tools such as Photoshop as easily is an open question. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 17:56 ` Bakul Shah @ 2020-01-18 2:11 ` Michael Parson 0 siblings, 0 replies; 118+ messages in thread From: Michael Parson @ 2020-01-18 2:11 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Thu, 9 Jan 2020, Bakul Shah wrote: > On Jan 9, 2020, at 9:21 AM, Jon Steinhart <jon@fourwinds.com> wrote: >> >> It's for that reason that I hate the addition of multiple windows to vi. I >> already have a windowing system on my machine, and that's what I use for windows. >> To me, the correct thing to do is to open a new desktop window to edit a new file >> and start a new instance of vi, not to use vi to open another internal window. > > The Rand editor made good use of multiple windows. You could set things up so > that two windows would scroll *in sync*. This is handy e.g. when you are looking > at two columns or rows that far apart in the same file or in different files and > too large so you need to scroll. For your .vimrc: nmap =f :vsplit<bar>wincmd l<bar>exe "norm! Ljz<c-v><cr>"<cr>:set scb<cr>:wincmd h<cr>:set scb<cr> Don't remember where I picked that up, but this will give you two vim windows, showing your file in both, one-screen's worth apart, with synchronized scolling. -- Michael Parson Pflugerville, TX KF5LGQ ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 17:21 ` Jon Steinhart 2020-01-09 17:30 ` Warner Losh 2020-01-09 17:56 ` Bakul Shah @ 2020-01-09 18:53 ` Larry McVoy 2020-01-09 19:01 ` Jon Steinhart 2 siblings, 1 reply; 118+ messages in thread From: Larry McVoy @ 2020-01-09 18:53 UTC (permalink / raw) To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society On Thu, Jan 09, 2020 at 09:21:40AM -0800, Jon Steinhart wrote: > It's for that reason that I hate the addition of multiple windows to vi. That's just silly. I frequently open two panes on the same file. Lets compare: Your way: - click to open a new terminal - click on it because it's not where I want, move it - cd to where ever I am - vi whatever My way: :sp You are welcome to your opinion but to argue that multiple panes in vi aren't useful, fine, maybe not to you. Don't use them. Other people love that feature, that feature is why I tried emacs many years ago. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 18:53 ` Larry McVoy @ 2020-01-09 19:01 ` Jon Steinhart 0 siblings, 0 replies; 118+ messages in thread From: Jon Steinhart @ 2020-01-09 19:01 UTC (permalink / raw) To: The Eunuchs Hysterical Society Larry McVoy writes: > On Thu, Jan 09, 2020 at 09:21:40AM -0800, Jon Steinhart wrote: > > It's for that reason that I hate the addition of multiple windows to vi. > > That's just silly. I frequently open two panes on the same file. Lets > compare: > > Your way: > - click to open a new terminal > - click on it because it's not where I want, move it > - cd to where ever I am > - vi whatever > > My way: > :sp > > You are welcome to your opinion but to argue that multiple panes in > vi aren't useful, fine, maybe not to you. Don't use them. Other > people love that feature, that feature is why I tried emacs many > years ago. Yes, that is my opinion and clearly yours is different. Being as I have a huge hi-res screen, I often have other windows open and ready to do, so all I have to do is move the mouse. But really to me you're opening yet another can of worms, which is what I call the "string theory school of design" where every new program creates its own universe instead of functioning in the existing one. I'm working on a demonstration project to illuminate a different path, but it's gonna be a while before I have something to show. Jon ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 15:54 ` Clem Cole 2020-01-09 17:21 ` Jon Steinhart @ 2020-01-09 19:02 ` Steffen Nurpmeso 2020-01-09 19:19 ` Steffen Nurpmeso 2020-01-09 20:20 ` Mary Ann Horton 2 siblings, 1 reply; 118+ messages in thread From: Steffen Nurpmeso @ 2020-01-09 19:02 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society, Computer Old Farts Followers Clem Cole wrote in <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@\ mail.gmail.com>: |Answering, but CCing COFF if folks want to continue. This is less \ |about UNIX and more about how we all got to where we are. ... To me endless undo of vim is great, and i am used to it. I think i could compile a version from ~20 years ago, supposed to be much smaller, and i would be ok with it. You have other windows open, ok, but you have typed this in a browser that consumes more memory than all the programs running here altogether have (real), within a codebase that consists of millions and millions lines of code. I mean hey, even though decades of development and tens of thousands of eyes passed, i see super simple compiler errors in gcc and clang, and except for optimization maybe not that much improvement in useful diagnostics, even though the executables are 150 times and more greater than that. For example i have a netrc parser which uses a fixed size target buffer, in a 90 lines function, with comments, empty lines, and a static structure of token types to test-iterate against, and with a possibly *off++=by;*off='\0'; one, but it took a Coverity.com run to detect it. (Actually it is worse, because this code is from 2014, and it seems only the combination of gcc 8.3.0 and the current cov-analysis-linux64-2019.03 could find it; not in August, when i checked for the second to last, but only for the last check.) |Let me take a look at this issue in a different way. I have long \ |been a 'car guy' and like many of those times in my youth spent time \ |and money playing/racing etc. I've always thought electric was a |great idea/but there has been nothing for me. Note: As many of you \ |know my work in computers has been in HPC, and I've been lucky to spend \ |a lot of time with my customers, in the auto and aerospace |industry (i.e. the current Audi A6 was designed on one of my supercomputer \ |systems). The key point is have tended to follow technology in their \ |area and tend to "in-tune" with a lot of developments. |The result, except for my wife's minivan (that she preferred in the \ |years when our kids were small), I've always been a die-hard German-eng\ |ineered/performance car person. But when Elon announced |the Model 3 (like 1/2 the techie world), I put down a deposit and waited. | |Well why I was waiting, my techie daughter (who also loves cars), got \ |a chance to drive one. She predicted I would hate it!!! So when my \ |ticket finally came up, I went to drive them. She was right!!! |With the Model 3, you get a cool car, but it's about the size of a \ |Corrolla. Coming from Germans cars for the last 35 years, the concept \ |of spending $60K US in practice for a Corrolla just did not do it |for me. I ended up ordering the current Unixmobile, my beloved Tesla \ |Model S/P100D. Corolla is not $60K. So you want 500 horse power, maybe. |The truth is, I paid a lot of money for it but I value what I got for \ |my money. A number of people don't think it's worth it. I get that, \ |but I'm still happy with what I have. Will there someday be a |$20K electric car like my Model S? While I think electric cars will \ |get there (I point out the same price curve on technology such microwave \ |ovens from the 1970so today), but I actually doubt that there |will be a $20K electric vehicle like my Model S. Well, lucky you that you can and want to spend that much money for a, hm, car. |The reason is that to sell this car because it as to be expensive for \ |technology-based reasons, so Tesla had to add a lot of 'luxury' features \ |like other cars in the class, other sports cars, Mercedes, | et al. As they removed them (i.e. the Model 3) you still get a cool \ |car, but it's not at all the same as the Model S. So the point is, \ |if I wanted an electric car, I had to choose between a |performance/luxury vs. size/functionality. I realized I valued the \ |former (and still do), but I understand not everyone does or will. So i for one _totally_ - totally! - disagree. It really drives me up the wall. You drive around with a 600 kilogramm or even heavier battery. You car is about 2000 kilogram. That is a lot of resource that needs to be digged, transported, assembled .. recycled, as far as that is possible. It increases the load on the streets, you know, trucks have a factor of an impact higher than cars. I mean, in America the difference is maybe not that big since the average car is very big on its own, i think a pick up is the most-selled car there for many years, with each instance being worth at least 2 of the German and Austrian etc. top seller. You can add to that entire Europe, including England. The entire car community did know at the end of the 80s / beginning of the 90s what is necessary for better Otto and Diesel engines, and as of today, thirty years later!, not all engines are actually using these technologies. There is nothing new at all regarding technology, nothing!, except of course materials engineering and robotics. That is a political declaration of bankruptcy. And i hate BMW top managers starting over with "the problem is not the SUV driver, the problem is the 15 year old family shooting brake". That is antisocial, ignorant, reckless and homicidal. And it was clear what the future after those combustion engines will be, and that is hydrogen. That is fuell cell and tank in sandwich floor, with wheel hub motors. The latter has always been my favourite, even though it could increase moved mass, but i do not know. So 120 years after wheel hub we choose two on-axe to reduce production cost. That is composite material. Luckily even some market-based industries have shown the fertility and will to develop further beyond what was there about 120 years ago, unfortunately we the Germans not, except for rare military developments, also decades ago. I said 26 years ago the best would be if each and every citizen would gain such a chassis, and the body would be up to each and everyone, [why not] with some "Trabant 601 based default". Even Tesla was interesting, fifteen or so years ago. Because they used the Lotus Elite chassis, which is about <800 Kilogramm. I personally am and always have been a total fan of Chapman's Philosophy, the lighter, the more beautiful. And if you want comfort and industrial mass production, take the Mazda MX-5, it is 1000 Kilogramm, and has 160 horse power. Your Tesla is still more powerful, because it has more than 320 horse power, but it is much heavier around the corners, and much much less swift. Of course, i see here in Germany in practice all men above 50 need their SUV now (thanks America for this future relevant trend), and they look relaxed, meaningful, potent. Yet they are not. See above. And they are not, beyond that. They reflect reckless degeneration. Yes, the white men's sperm production has halved, their allergies and woewoes have increased, their abuse of substances is enormous, and different to normal native human beings, entirely senseless and not embedded into any cultural surroundings. I mean, the heck. This wave has started, we now already explore digging much more of the necessary resources in the Atacama and maybe already in some Portuguese nature resource. We have interesting things which are maybe ok, like the Honda e. In the ever growing mega cities with the necessary infrastructure "i allow you to" use such city cars. It may make sense. What does not make sense is installing thousands of kilometers of copper cable to build up an infrastructure for high voltage battery filling. Really. That is copper. You know how much resources are required to produce copper? And in third countries our industry does not even give the minimum shit and uses the cheap most poisening elements to do its dirty work. No! Yes, just this week i think the German "Die Zeit" had an article on trash, trash everywhere, the trash island in the pacific is now as large as Texas they said, i know i have read about this island of trash in an early 80s book on open sea (sailing) accidents at the friend of my father, about 35 years ago, i blindly assume it was smaller by then. So only the one copper factory in Germany he was writing about produces more Trash than all European households altogether. That is just one. No! But there you go along with batteries. I mean they (Tesla) seem to have made their homework regarding crash safety, though i also disliked the crash test standards 26 years ago, and still back crashs are not tested, and they bang a solid cube regardless of the misalignment of at least the major masses that happens in practice if an Escalade hits an AMC Pacer. They seem to have created a new user experience that is also much cheaper to build (i do not like it), the cars have a tremendous power, and California has a nifty Energy Mix and infrastructure to satisfy full throttle fun. (Maybe.) I admit i was happy once a german car manager said dismissive words about Tesla (yesyesyes!), but again, just to find out they were doing and heading out for exactly the same. Except battery technology, maybe. Yes, i think the Porsche Taycan has an interesting design, i like especially the profile, i could maybe even like the interieur, for that one, but it is too heavy and uses the wrong technology. And no wood. I for one would not spend that much money for a car anyway, but if, definitely not like that. If i buy a CRV Hybrid, or a Suzuki Vitara, then i can buy a Caterham, a Lotus Elise, and almost a Morgan 3-Wheeler all in addition to end up at that price. See, the latter three are almost hand-built by human beings which perform craftsmanship, they do real jobs, and can go home prowd or at least somewhat fullfilled. Small companies. Buying and refining mass production engines (here Ford, Toyota, and S&S). And the CRV technology will at later times simply replace the combustion engine with a fuell cell. And it has some natural thing in it, a wooden strip. I personally like the Vitara, because it is only 1300 kilogramm, can tow enough for me, has a glass roof that can be opened, has LED lamps, does not contain any leather (no more), and if they will use the cylinder deactivation that i demanded almost thirty years ago, and maybe bring in the little Hybrid system they now introduce to their Ignis and Swift, i would go for it. The new Subaru Forester has a 16.7 horsepower electrical add-on. Enough for city traffic jam stop and go! Fiat has the wonderful two-cylindre engine in Panda and 500, 85 to 105 horsepower. A wonderful engine! Ford also, it has a wonderful three-cylindre engine. (I am talking Europe here, mind you.) And next year -- and here it comes! -- next year Toyota will come over with the new Mirai, real fuel-cell, refined, and not as a SUV!, and i think i will buy myself that one. |Coming back to our topic, I really don't think this is a 'get my lawn' \ |issue as much, as asking someone what they really value/what they really \ |need. If you place a high-value you something, you will |argue that its best; if it has little value you will not. In the end all that is industrial shit. If you are a lucky man you are science or worked at Bell Labs. The rest is all industrial shit, may it be pharmacy or medicine or whatever else. With all the little ones trying to get their place at the sun, recklessly. It is up to everyone to work on its own reflection and awareness, and to bring that work into all the many which are incapable to or uninterested in doing that. And unfortunately most do not. They are never shown, too, which makes me sad. I will now listen to the Westminster Abbey chorus singing Miserere mei Deus, just to let you know. And think how it must have been by then, with simplemost illnesses and wounds killing everyone from poor to rich, and with bad weather or other pest causing starvation and death, with regional food only, if you were lucky, not kilos of meat with cost backlog every day, when in early morning hours in a dark church the first sunlight would fall through handcrafted art- and passionful windows. --End of <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail\ .com> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 19:02 ` Steffen Nurpmeso @ 2020-01-09 19:19 ` Steffen Nurpmeso 0 siblings, 0 replies; 118+ messages in thread From: Steffen Nurpmeso @ 2020-01-09 19:19 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society, Computer Old Farts Followers Steffen Nurpmeso wrote in <20200109190219.bdHOi%steffen@sdaoden.eu>: |Clem Cole wrote in <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@\ |mail.gmail.com>: ... ||Let me take a look at this issue in a different way. I have long \ ||been a 'car guy' and like many of those times in my youth spent time \ ||and money playing/racing etc. I've always thought electric was a ||great idea/but there has been nothing for me. Note: As many of you \ .. ||Coming back to our topic, I really don't think this is a 'get my lawn' \ ||issue as much, as asking someone what they really value/what they really \ ||need. If you place a high-value you something, you will ||argue that its best; if it has little value you will not. What else. All the many, many reports and expert assessments which suddenly appear and point out to the last cent that and why battery cars are better for the environment than anything else, including fuell cell driven cars. Heck, how i hate those. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 15:54 ` Clem Cole 2020-01-09 17:21 ` Jon Steinhart 2020-01-09 19:02 ` Steffen Nurpmeso @ 2020-01-09 20:20 ` Mary Ann Horton 2 siblings, 0 replies; 118+ messages in thread From: Mary Ann Horton @ 2020-01-09 20:20 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 508 bytes --] Yes, I totally agree. NIH was rampant at Bell Labs in the 1980s. Management pushed us to use the internal tools rather than external tools we liked better. 3B vs Sun comes to mind. Datakit vs TCP/IP. Mary Ann On 1/9/20 7:54 AM, Clem Cole wrote: > Frankly, other than NIH, I'm not sure why the folks at AT&T decided to > create pg a few years later since more was already in the wild, but at > least it was a different program (Mary Ann's story of vi /vs/. se if > probably in the same vein). [-- Attachment #2: Type: text/html, Size: 946 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 4:23 ` Jon Steinhart 2020-01-09 15:54 ` Clem Cole @ 2020-01-18 2:06 ` Michael Parson 2020-01-18 3:13 ` Clem Cole 1 sibling, 1 reply; 118+ messages in thread From: Michael Parson @ 2020-01-18 2:06 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Wed, 8 Jan 2020, Jon Steinhart wrote: > Clem Cole writes: >> >> make a new command, don't break the old one.... maybe offer a way to map >> the new one over the old -- but don't make it the default. >> and my lawn was lush and green before the snow came ;-) > > Clem, this seems like an unusual position for you to take. vim is backwards > compatible with vi (and also ed), so it added to an existing ecosystem. It's like 99% compatible. The undo change bothered me a lot, I still don't really 'get' vim's undo method even having mostly given up on old vi about 10 years ago. I'm sure it's better, if I ever got around to learning it, but I agree with Clem, vim's 'enhanced unlmited undo' should have moved to a different keybinding. 'vim' also moved the "increment number" command to a new key. And the one that visually bothered me is 'cw' or 'c<anything>', immediately removes the text that's going to be replaced. I liked old vi's way of leaving it there for you to type over. -- Michael Parson Pflugerville, TX KF5LGQ ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-18 2:06 ` Michael Parson @ 2020-01-18 3:13 ` Clem Cole 2020-01-18 3:44 ` Kurt H Maier 2020-01-18 15:37 ` Larry McVoy 0 siblings, 2 replies; 118+ messages in thread From: Clem Cole @ 2020-01-18 3:13 UTC (permalink / raw) To: Michael Parson; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 574 bytes --] On Fri, Jan 17, 2020 at 9:35 PM Michael Parson <mparson@bl.org> wrote: > It's like 99% compatible. Exactly... As my old (non-PC) 10th-grade calculus teacher used to say, "I'll give you partial credit when you can bring be me a female that is partially pregnant." To be you are either compatible or not. I would have been ok to have had an option that you could turn on that gave you new behavior (but make the user turn it on thank you). BTW: the cX command's behavior I also find annoying visually, but it does not screw up 30-40 years of programming in my fingers. [-- Attachment #2: Type: text/html, Size: 1511 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-18 3:13 ` Clem Cole @ 2020-01-18 3:44 ` Kurt H Maier 2020-01-18 15:37 ` Larry McVoy 1 sibling, 0 replies; 118+ messages in thread From: Kurt H Maier @ 2020-01-18 3:44 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society On Fri, Jan 17, 2020 at 10:13:45PM -0500, Clem Cole wrote: > On Fri, Jan 17, 2020 at 9:35 PM Michael Parson <mparson@bl.org> wrote: > > > It's like 99% compatible. > > Exactly... As my old (non-PC) 10th-grade calculus teacher used to say, > "I'll give you partial credit when you can bring be me a female that is > partially pregnant." > > To be you are either compatible or not. I would have been ok to have had > an option that you could turn on that gave you new behavior (but make the > user turn it on thank you). > > BTW: the cX command's behavior I also find annoying visually, but it does > not screw up 30-40 years of programming in my fingers. There was a time when, by default, vim started in 'compatible' mode, in which u didn't ignore u, so you got the toggle-style undo. Compatible mode also keeps the ol$ style of c representation, and so forth. You can still force this by making a ~/.vimrc file that just contains set compatible I don't remember when vim stopped launching in compatible mode by default, but that was basically when I stopped using it. I only figured out how to force it back because it's on all the linux computers I run into at work. As I recall, the 'set compatible' command is shorthand to set all the vi-compatibility flags by default; it is possible to set them individually as well. So your proposal is (was?) at least implemented, if not in a very useful manner. khm ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-18 3:13 ` Clem Cole 2020-01-18 3:44 ` Kurt H Maier @ 2020-01-18 15:37 ` Larry McVoy 2020-01-18 22:11 ` markus schnalke 1 sibling, 1 reply; 118+ messages in thread From: Larry McVoy @ 2020-01-18 15:37 UTC (permalink / raw) To: Clem Cole; +Cc: The Eunuchs Hysterical Society On Fri, Jan 17, 2020 at 10:13:45PM -0500, Clem Cole wrote: > On Fri, Jan 17, 2020 at 9:35 PM Michael Parson <mparson@bl.org> wrote: > > > It's like 99% compatible. > > Exactly... As my old (non-PC) 10th-grade calculus teacher used to say, > "I'll give you partial credit when you can bring be me a female that is > partially pregnant." > > To be you are either compatible or not. I would have been ok to have had > an option that you could turn on that gave you new behavior (but make the > user turn it on thank you). It's rare event when I disagree with you, Clem (sometimes it seems like we were separated at birth :) If it was compat by default then you wouldn't learn any of the new stuff. set compatible isn't that hard but we'd have to read docs to find that. Anyhoo, cross reference to Ted's thought that Linux didn't have to deal with the Gods of BSD so they could rip stuff out and try again, his point is that worked better than the BSD way. Compat is fine but if you want progress, sometimes you break compat. For me, I've got a .exrc that I've been carrying around for decades (has maps in it for some compat bindings to an editor I used on CP/M, it's _that_ old) and vim is perfectly happy with it. I mostly use vim as a vi compat but I regularly use 2 panes, that's super useful. It's progress and you can have compat mode easily, seems like a win. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-18 15:37 ` Larry McVoy @ 2020-01-18 22:11 ` markus schnalke 0 siblings, 0 replies; 118+ messages in thread From: markus schnalke @ 2020-01-18 22:11 UTC (permalink / raw) To: tuhs Hoi. Not wanting to heaten this rather annoying editor discussion, but as no one yet has mentioned argv[0]: [2020-01-18 07:37] Larry McVoy <lm@mcvoy.com> > On Fri, Jan 17, 2020 at 10:13:45PM -0500, Clem Cole wrote: > > > > To be you are either compatible or not. I would have been ok to have had > > an option that you could turn on that gave you new behavior (but make the > > user turn it on thank you). > If it was compat by default then you > wouldn't learn any of the new stuff. > set compatible Shouldn't all that be solved by acting compatible if called as `vi' and being free from compatibility bounds when called as `vim'? If I say `vi' I want a vi. If I want Vim, I say so. (No matter if these are links to the same binary.) Problem solved. Everyone happy? meillo ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 1:28 ` Larry McVoy 2020-01-09 1:40 ` Bakul Shah @ 2020-01-09 2:14 ` Greg 'groggy' Lehey 2020-01-09 2:48 ` Chet Ramey 1 sibling, 1 reply; 118+ messages in thread From: Greg 'groggy' Lehey @ 2020-01-09 2:14 UTC (permalink / raw) To: Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 825 bytes --] On Wednesday, 8 January 2020 at 17:28:30 -0800, Larry McVoy wrote: > On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote: >> Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD >> default for vi. > > I was gonna stay out of this thread (it has the feel of old folks somehow) > but 2 comments: > > Keith did nvi (I can't remember why? licensing or something) My vague recollection is that Rob Kolstad paid him to do it for BSD/386. As you say, licensing, and that BSD/386 *really* needed a vi editor. Does anybody know where Rob is? Greg -- Sent from my desktop computer. Finger grog@lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 163 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 2:14 ` Greg 'groggy' Lehey @ 2020-01-09 2:48 ` Chet Ramey 0 siblings, 0 replies; 118+ messages in thread From: Chet Ramey @ 2020-01-09 2:48 UTC (permalink / raw) To: Greg 'groggy' Lehey, Larry McVoy; +Cc: The Eunuchs Hysterical Society [-- Attachment #1.1: Type: text/plain, Size: 473 bytes --] On 1/8/20 9:14 PM, Greg 'groggy' Lehey wrote: > My vague recollection is that Rob Kolstad paid him to do it for > BSD/386. As you say, licensing, and that BSD/386 *really* needed a vi > editor. > > Does anybody know where Rob is? Colorado Springs, according to Twitter. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 235 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 0:08 ` Warner Losh 2020-01-09 1:28 ` Larry McVoy @ 2020-01-09 9:05 ` Thomas Paulsen 1 sibling, 0 replies; 118+ messages in thread From: Thomas Paulsen @ 2020-01-09 9:05 UTC (permalink / raw) To: Warner Losh; +Cc: tuhs > Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD default for vi. check out elvis https://github.com/mbert/elvis vi + syntax highlighting + clean help subsystem = ~ 25% of size of vim ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 9:46 Rudi Blom 2020-01-08 14:15 ` Chet Ramey @ 2020-01-08 15:11 ` Nemo Nusquam 2020-01-08 15:37 ` Henry Bent 2020-01-18 14:22 ` Michael Parson 1 sibling, 2 replies; 118+ messages in thread From: Nemo Nusquam @ 2020-01-08 15:11 UTC (permalink / raw) To: tuhs On 01/08/20 04:46, Rudi Blom wrote: > That's a real big vi in RHL. Looking at a few (commercial) unixes I get > SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi > - /usr/bin/vi: iAPX 386 executable > Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi > - /usr/bin/vi: COFF format alpha dynamically linked, demand paged > sticky executable or object module stripped - version 3.13-14 > HP-UX 11.31 748996 Aug 28 2009 /bin/vi > -- /bin/vi: ELF-32 executable object file - IA64 Solaris 10 on Ultrasparc 239828 /usr/bin/vi: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped Any others? N. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 15:11 ` Nemo Nusquam @ 2020-01-08 15:37 ` Henry Bent 2020-01-18 14:22 ` Michael Parson 1 sibling, 0 replies; 118+ messages in thread From: Henry Bent @ 2020-01-08 15:37 UTC (permalink / raw) To: Nemo Nusquam; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 984 bytes --] On Wed, 8 Jan 2020 at 10:20, Nemo Nusquam <cym224@gmail.com> wrote: > On 01/08/20 04:46, Rudi Blom wrote: > > That's a real big vi in RHL. Looking at a few (commercial) unixes I get > > SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi > > - /usr/bin/vi: iAPX 386 executable > > Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi > > - /usr/bin/vi: COFF format alpha dynamically linked, demand paged > > sticky executable or object module stripped - version 3.13-14 > > HP-UX 11.31 748996 Aug 28 2009 /bin/vi > > -- /bin/vi: ELF-32 executable object file - IA64 > > Solaris 10 on Ultrasparc 239828 > /usr/bin/vi: ELF 32-bit MSB executable SPARC Version 1, > dynamically linked, stripped > > Any others? > I was somewhat surprised by this, on IRIX 4.0.5H: /usr/bin/vi: symbolic link to ex -rwxr-xr-t 1 root sys 229376 2016-04-17 01:07 /usr/bin/ex /usr/bin/ex: mipseb demand paged stripped - version 2.10 % what /usr/bin/ex /usr/bin/ex: printf.c:2.2 6/5/79 -Henry [-- Attachment #2: Type: text/html, Size: 1443 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-08 15:11 ` Nemo Nusquam 2020-01-08 15:37 ` Henry Bent @ 2020-01-18 14:22 ` Michael Parson 1 sibling, 0 replies; 118+ messages in thread From: Michael Parson @ 2020-01-18 14:22 UTC (permalink / raw) To: tuhs On Wed, 8 Jan 2020, Nemo Nusquam wrote: > On 01/08/20 04:46, Rudi Blom wrote: >> That's a real big vi in RHL. Looking at a few (commercial) unixes I get >> SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi >> - /usr/bin/vi: iAPX 386 executable >> Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi >> - /usr/bin/vi: COFF format alpha dynamically linked, demand paged >> sticky executable or object module stripped - version 3.13-14 >> HP-UX 11.31 748996 Aug 28 2009 /bin/vi >> -- /bin/vi: ELF-32 executable object file - IA64 > > Solaris 10 on Ultrasparc 239828 > /usr/bin/vi: ELF 32-bit MSB executable SPARC Version 1, dynamically > linked, stripped > > Any others? I've been playing with this for the last few months: $ uname -a UNIX_System_V amix 4.0 2.1c 0800430 Amiga (Unlimited) m68k $ file /usr/bin/vi /usr/bin/vi: ELF 32-bit MSB executable M68000 Version 1 -- Michael Parson Pflugerville, TX KF5LGQ ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors @ 2020-01-09 21:46 Norman Wilson 2020-01-09 22:10 ` Brantley Coile 0 siblings, 1 reply; 118+ messages in thread From: Norman Wilson @ 2020-01-09 21:46 UTC (permalink / raw) To: tuhs Do we really need another boring old editor war? The topic is not specific to UNIX in the least; nor, alas, is it historic. Norman Wilson Toronto ON (typing this in qed) ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] screen editors 2020-01-09 21:46 Norman Wilson @ 2020-01-09 22:10 ` Brantley Coile 0 siblings, 0 replies; 118+ messages in thread From: Brantley Coile @ 2020-01-09 22:10 UTC (permalink / raw) To: Norman Wilson; +Cc: tuhs Why not? It's kind of nostalgic. I got to watch my first editor war back in 1983 on my newly installed netnews. The reasoning seems to be the same, only the names have changed. But then again, your reasoning makes sense. And besides, it's been all down hill since qed. > On Jan 9, 2020, at 4:46 PM, Norman Wilson <norman@oclsc.org> wrote: > > Do we really need another boring old editor war? The topic > is not specific to UNIX in the least; nor, alas, is it historic. > > Norman Wilson > Toronto ON > (typing this in qed) ^ permalink raw reply [flat|nested] 118+ messages in thread
[parent not found: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es>]
* Re: [TUHS] Screen editors [not found] <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> @ 2020-01-20 14:59 ` Jose R. Valverde via TUHS 2020-01-20 16:07 ` Toby Thain 2020-01-26 18:28 ` arnold 0 siblings, 2 replies; 118+ messages in thread From: Jose R. Valverde via TUHS @ 2020-01-20 14:59 UTC (permalink / raw) To: tuhs Talking of editors... Once I learned Wordstar in old CP/M (before that it was mostly line editing), and then soon, other editors that supported the Wordstar key combinations, I got hooked on those. Joe is, to date, one of my favorites. On ancient UNIX, my editor of choice was 's' from Software Tools, its main advantage being that it didn't require curses. Then we got VMS and 'eve' and that took over for a while (though I never took advantage of all its power), mostly until I ported 's' and 'joe'. Then came X, and when nedit was released, I was hooked on it. It has been for decades almost the only one that could do block selection 'a la' RAND editor. I have been struggling to continue using it despite it lack of support for UTF, trying various projects spun off nedit, until I recently discovered xnedit, which is an update available on GitHub and is again all I need, with support for UTF8, some minor UI improvements and support for modern fonts. Now, I still use 's' for ancient Unix emulators, 'joe' for the command line and 'xnedit' for X. j -- Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-20 14:59 ` [TUHS] Screen editors Jose R. Valverde via TUHS @ 2020-01-20 16:07 ` Toby Thain 2020-01-20 16:20 ` Larry McVoy 2020-01-29 22:24 ` Dave Horsfall 2020-01-26 18:28 ` arnold 1 sibling, 2 replies; 118+ messages in thread From: Toby Thain @ 2020-01-20 16:07 UTC (permalink / raw) To: Jose R. Valverde, tuhs On 2020-01-20 9:59 AM, Jose R. Valverde via TUHS wrote: > Talking of editors... > > Once I learned Wordstar in old CP/M (before that it was mostly line > editing), and then soon, other editors that supported the Wordstar key > combinations, I got hooked on those. Joe is, to date, one of my > favorites. Speaking of WordStar, on CP/M there was also WordMaster, lighter weight, better as a programmer's editor. Not sure who wrote it (but istr it came from the WordStar people?) Adding here for completeness... --T > > On ancient UNIX, my editor of choice was 's' from Software Tools, ... > > Now, I still use 's' for ancient Unix emulators, 'joe' for the > command line and 'xnedit' for X. > > j > ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-20 16:07 ` Toby Thain @ 2020-01-20 16:20 ` Larry McVoy 2020-01-31 18:21 ` Jose R. Valverde via TUHS 2020-01-29 22:24 ` Dave Horsfall 1 sibling, 1 reply; 118+ messages in thread From: Larry McVoy @ 2020-01-20 16:20 UTC (permalink / raw) To: Toby Thain; +Cc: tuhs On Mon, Jan 20, 2020 at 11:07:01AM -0500, Toby Thain wrote: > On 2020-01-20 9:59 AM, Jose R. Valverde via TUHS wrote: > > Talking of editors... > > > > Once I learned Wordstar in old CP/M (before that it was mostly line > > editing), and then soon, other editors that supported the Wordstar key > > combinations, I got hooked on those. Joe is, to date, one of my > > favorites. > > Speaking of WordStar, on CP/M there was also WordMaster, lighter weight, > better as a programmer's editor. Not sure who wrote it (but istr it came > from the WordStar people?) Adding here for completeness... My memory fu is weak but there was a small editor for CP/M that I liked a lot. Can't remember what it was called but I stole some keybindings from it: map # :.,$ # does from here to the bottom map @ :1,. @ does from top to here Anyone remember that? ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-20 16:20 ` Larry McVoy @ 2020-01-31 18:21 ` Jose R. Valverde via TUHS 0 siblings, 0 replies; 118+ messages in thread From: Jose R. Valverde via TUHS @ 2020-01-31 18:21 UTC (permalink / raw) To: tuhs I may have a digitized copy of the book, but don't bet on it. Some years ago I decided I wanted to have an electronic copy of some of my books so I could peruse them more easily, In the end I think I only got around digitizing a couple of them. This was also after I had lent a great book on Logo with plenty of algorithms on (old-style) AI and never got it back. Didn't know Miller had come into Bioinformatics as well (or if I did, I didn't connect him to the book). I've been on Bioinformatics since '84. j -- Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-20 16:07 ` Toby Thain 2020-01-20 16:20 ` Larry McVoy @ 2020-01-29 22:24 ` Dave Horsfall 2020-01-29 22:33 ` Larry McVoy 2020-01-29 23:00 ` Thomas Paulsen 1 sibling, 2 replies; 118+ messages in thread From: Dave Horsfall @ 2020-01-29 22:24 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Mon, 20 Jan 2020, Toby Thain wrote: > Speaking of WordStar, on CP/M there was also WordMaster, lighter weight, > better as a programmer's editor. Not sure who wrote it (but istr it came > from the WordStar people?) Adding here for completeness... I used WordStar a lot on my old Microbee (an Aussie CP/M box) but I never heard of WordMaster... Getting a full ANSI C compiler for CP/M was great; I could use some Unix tools on it :-) Can't remember if it was BDS or Hi-Tech; one was ANSI (function prototypes and the works) whereas the other wouldn't even recognise things like "int i = 1;". I even found a UUCP for it too, but it was overlaid to hell and back; at least it worked... -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-29 22:24 ` Dave Horsfall @ 2020-01-29 22:33 ` Larry McVoy 2020-02-07 23:05 ` Dave Horsfall 2020-01-29 23:00 ` Thomas Paulsen 1 sibling, 1 reply; 118+ messages in thread From: Larry McVoy @ 2020-01-29 22:33 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society On Thu, Jan 30, 2020 at 09:24:13AM +1100, Dave Horsfall wrote: > On Mon, 20 Jan 2020, Toby Thain wrote: > > >Speaking of WordStar, on CP/M there was also WordMaster, lighter weight, > >better as a programmer's editor. Not sure who wrote it (but istr it came > >from the WordStar people?) Adding here for completeness... > > I used WordStar a lot on my old Microbee (an Aussie CP/M box) but I never > heard of WordMaster... > > Getting a full ANSI C compiler for CP/M was great; I could use some Unix > tools on it :-) Can't remember if it was BDS or Hi-Tech; one was ANSI > (function prototypes and the works) whereas the other wouldn't even > recognise things like "int i = 1;". BDS was pretty good about C, I used it a *lot*, but it had a really funky not compatible libc/stdio. I got used to it but had to retrain my brain when I was on Unix. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-29 22:33 ` Larry McVoy @ 2020-02-07 23:05 ` Dave Horsfall 2020-02-07 23:54 ` Richard Salz 2020-02-08 0:05 ` Bakul Shah 0 siblings, 2 replies; 118+ messages in thread From: Dave Horsfall @ 2020-02-07 23:05 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Wed, 29 Jan 2020, Larry McVoy wrote: >> Getting a full ANSI C compiler for CP/M was great; I could use some >> Unix tools on it :-) Can't remember if it was BDS or Hi-Tech; one was >> ANSI (function prototypes and the works) whereas the other wouldn't >> even recognise things like "int i = 1;". > > BDS was pretty good about C, I used it a *lot*, but it had a really > funky not compatible libc/stdio. I got used to it but had to retrain my > brain when I was on Unix. I remember now; it was Hi-Tech C (an Aussie company) that was full ANSI; BDS C could barely compile C... I think it was Henry Spencer who said something like "Somehow, to be called a C compiler it ought to at least compile C" (I don't think he was referring to BDS C, though). -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-02-07 23:05 ` Dave Horsfall @ 2020-02-07 23:54 ` Richard Salz 2020-02-08 3:11 ` Dave Horsfall 2020-02-08 0:05 ` Bakul Shah 1 sibling, 1 reply; 118+ messages in thread From: Richard Salz @ 2020-02-07 23:54 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 210 bytes --] BDS C stood for Brain-Damaged Software, it was the work of one guy (Leor Zolman). I think it was used to build the Mark of the Unicorn stuff (MINCE, Mince is not complete emacs, and Scribble, a scribe clone). [-- Attachment #2: Type: text/html, Size: 237 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-02-07 23:54 ` Richard Salz @ 2020-02-08 3:11 ` Dave Horsfall 2020-02-08 3:38 ` Ronald Natalie 0 siblings, 1 reply; 118+ messages in thread From: Dave Horsfall @ 2020-02-08 3:11 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Fri, 7 Feb 2020, Richard Salz wrote: > BDS C stood for Brain-Damaged Software [...] Yes, I've heard it called that :-) It sure was... -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-02-08 3:11 ` Dave Horsfall @ 2020-02-08 3:38 ` Ronald Natalie 0 siblings, 0 replies; 118+ messages in thread From: Ronald Natalie @ 2020-02-08 3:38 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 611 bytes --] Amusingly, I was a co-owner of a company called BDS (not the C complier people). I knew the BDS-C people existed having been a customer for a while. I got the BDS.COM <http://bds.com/> domain early on. We promptly changed our name after an acquisition, and I let the Bds people have our old domain for nothing when they inquired if we were done with it. > On Feb 8, 2020, at 4:11 PM, Dave Horsfall <dave@horsfall.org> wrote: > > On Fri, 7 Feb 2020, Richard Salz wrote: > >> BDS C stood for Brain-Damaged Software [...] > > Yes, I've heard it called that :-) It sure was... > > -- Dave [-- Attachment #2: Type: text/html, Size: 1260 bytes --] ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-02-07 23:05 ` Dave Horsfall 2020-02-07 23:54 ` Richard Salz @ 2020-02-08 0:05 ` Bakul Shah 1 sibling, 0 replies; 118+ messages in thread From: Bakul Shah @ 2020-02-08 0:05 UTC (permalink / raw) To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society On Sat, 08 Feb 2020 10:05:27 +1100 Dave Horsfall <dave@horsfall.org> wrote: > On Wed, 29 Jan 2020, Larry McVoy wrote: > > >> Getting a full ANSI C compiler for CP/M was great; I could use some > >> Unix tools on it :-) Can't remember if it was BDS or Hi-Tech; one was > >> ANSI (function prototypes and the works) whereas the other wouldn't > >> even recognise things like "int i = 1;". > > > > BDS was pretty good about C, I used it a *lot*, but it had a really > > funky not compatible libc/stdio. I got used to it but had to retrain my > > brain when I was on Unix. > > I remember now; it was Hi-Tech C (an Aussie company) that was full ANSI; > BDS C could barely compile C... > > I think it was Henry Spencer who said something like "Somehow, to be > called a C compiler it ought to at least compile C" (I don't think he was > referring to BDS C, though). You can see for yourself! The compiler is written in assembler! https://github.com/k0gaMSX/legacy/tree/master/PROG/C/BDS https://github.com/pbetti/ZDS/tree/master/software/bdsc There is lots of other stuff including other C compilers, Pascal, Basic, games etc. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-29 22:24 ` Dave Horsfall 2020-01-29 22:33 ` Larry McVoy @ 2020-01-29 23:00 ` Thomas Paulsen 1 sibling, 0 replies; 118+ messages in thread From: Thomas Paulsen @ 2020-01-29 23:00 UTC (permalink / raw) To: Dave Horsfall; +Cc: tuhs also I never heard of WordMaster! --- Ursprüngliche Nachricht --- Von: Dave Horsfall <dave@horsfall.org> Datum: 29.01.2020 23:24:13 An: The Eunuchs Hysterical Society <tuhs@tuhs.org> Betreff: Re: [TUHS] Screen editors On Mon, 20 Jan 2020, Toby Thain wrote: > Speaking of WordStar, on CP/M there was also WordMaster, lighter weight, > better as a programmer's editor. Not sure who wrote it (but istr it came > from the WordStar people?) Adding here for completeness... I used WordStar a lot on my old Microbee (an Aussie CP/M box) but I never heard of WordMaster... Getting a full ANSI C compiler for CP/M was great; I could use some Unix tools on it :-) Can't remember if it was BDS or Hi-Tech; one was ANSI (function prototypes and the works) whereas the other wouldn't even recognise things like "int i = 1;". I even found a UUCP for it too, but it was overlaid to hell and back; at least it worked... -- Dave ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-20 14:59 ` [TUHS] Screen editors Jose R. Valverde via TUHS 2020-01-20 16:07 ` Toby Thain @ 2020-01-26 18:28 ` arnold 2020-01-26 18:33 ` Adam Thornton ` (2 more replies) 1 sibling, 3 replies; 118+ messages in thread From: arnold @ 2020-01-26 18:28 UTC (permalink / raw) To: txomsy, tuhs "Jose R. Valverde via TUHS" <tuhs@minnie.tuhs.org> wrote: > Talking of editors... > > On ancient UNIX, my editor of choice was 's' from Software Tools, its > main advantage being that it didn't require curses. That editor was from "A Software Tools Sampler" by Webb Miller, not "Software Tools" by Kernighan and Plauger. I happened to pull out my copy of that book a week or so ago. It's truly strange looking at pre-ANSI / pre-POSIX code. I feel like that book did not have the same sort of eternally true value as the two Software Tools books do. Arnold ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-26 18:28 ` arnold @ 2020-01-26 18:33 ` Adam Thornton 2020-01-26 18:36 ` arnold 2020-01-26 18:40 ` arnold 2020-01-26 19:40 ` Jon Forrest 2020-01-26 20:08 ` Chet Ramey 2 siblings, 2 replies; 118+ messages in thread From: Adam Thornton @ 2020-01-26 18:33 UTC (permalink / raw) To: arnold; +Cc: tuhs > On Jan 26, 2020, at 11:28 AM, arnold@skeeve.com wrote: > > "Jose R. Valverde via TUHS" <tuhs@minnie.tuhs.org> wrote: > >> Talking of editors... >> >> On ancient UNIX, my editor of choice was 's' from Software Tools, its >> main advantage being that it didn't require curses. > > That editor was from "A Software Tools Sampler" by Webb Miller, not > "Software Tools" by Kernighan and Plauger. Well, that would explain why I couldn’t find it. Do you have softcopy of the editor source? I’d really like a screen editor for v7…. Adam ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-26 18:33 ` Adam Thornton @ 2020-01-26 18:36 ` arnold 2020-01-26 18:40 ` arnold 1 sibling, 0 replies; 118+ messages in thread From: arnold @ 2020-01-26 18:36 UTC (permalink / raw) To: athornton, arnold; +Cc: tuhs Adam Thornton <athornton@gmail.com> wrote: > > > > On Jan 26, 2020, at 11:28 AM, arnold@skeeve.com wrote: > > > > "Jose R. Valverde via TUHS" <tuhs@minnie.tuhs.org> wrote: > > > >> Talking of editors... > >> > >> On ancient UNIX, my editor of choice was 's' from Software Tools, its > >> main advantage being that it didn't require curses. > > > > That editor was from "A Software Tools Sampler" by Webb Miller, not > > "Software Tools" by Kernighan and Plauger. > > > Well, that would explain why I couldn’t find it. > > Do you have softcopy of the editor source? I’d really like a screen editor for v7…. > > Adam I don't. Maybe Jose does ... Arnold ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-26 18:33 ` Adam Thornton 2020-01-26 18:36 ` arnold @ 2020-01-26 18:40 ` arnold 2020-01-26 19:11 ` Adam Thornton 1 sibling, 1 reply; 118+ messages in thread From: arnold @ 2020-01-26 18:40 UTC (permalink / raw) To: athornton, arnold; +Cc: tuhs Adam Thornton <athornton@gmail.com> wrote: > > > > On Jan 26, 2020, at 11:28 AM, arnold@skeeve.com wrote: > > > > "Jose R. Valverde via TUHS" <tuhs@minnie.tuhs.org> wrote: > > > >> Talking of editors... > >> > >> On ancient UNIX, my editor of choice was 's' from Software Tools, its > >> main advantage being that it didn't require curses. > > > > That editor was from "A Software Tools Sampler" by Webb Miller, not > > "Software Tools" by Kernighan and Plauger. > > > Well, that would explain why I couldn’t find it. > > Do you have softcopy of the editor source? I’d really like a screen editor for v7…. > > Adam https://bio.psu.edu/directory/wcm2 is Webb Miller's home page, with an email address. Maybe you can get the code directly from him... Arnold ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-26 18:40 ` arnold @ 2020-01-26 19:11 ` Adam Thornton 0 siblings, 0 replies; 118+ messages in thread From: Adam Thornton @ 2020-01-26 19:11 UTC (permalink / raw) To: arnold; +Cc: tuhs > On Jan 26, 2020, at 11:40 AM, arnold@skeeve.com wrote: > > Adam Thornton <athornton@gmail.com> wrote: > >> >> >>> On Jan 26, 2020, at 11:28 AM, arnold@skeeve.com wrote: >>> >>> "Jose R. Valverde via TUHS" <tuhs@minnie.tuhs.org> wrote: >>> >>>> Talking of editors... >>>> >>>> On ancient UNIX, my editor of choice was 's' from Software Tools, its >>>> main advantage being that it didn't require curses. >>> >>> That editor was from "A Software Tools Sampler" by Webb Miller, not >>> "Software Tools" by Kernighan and Plauger. >> >> >> Well, that would explain why I couldn’t find it. >> >> Do you have softcopy of the editor source? I’d really like a screen editor for v7…. >> >> Adam > > https://bio.psu.edu/directory/wcm2 is Webb Miller's home page, with > an email address. Maybe you can get the code directly from him… I’ll try that. In the meantime I’ve added myself to the waitlist to borrow it from the Internet Archive. I’m a little surprised that the University of Arizona library doesn’t have a copy and neither do any of the other libraries their search engine can find. I’ll probably try to figure out how to Interlibrary Loan it, since that may well arrive faster than the IA version. Adam ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-26 18:28 ` arnold 2020-01-26 18:33 ` Adam Thornton @ 2020-01-26 19:40 ` Jon Forrest 2020-01-26 20:08 ` Chet Ramey 2 siblings, 0 replies; 118+ messages in thread From: Jon Forrest @ 2020-01-26 19:40 UTC (permalink / raw) To: tuhs On 1/26/2020 10:28 AM, arnold@skeeve.com wrote: > That editor was from "A Software Tools Sampler" by Webb Miller, not > "Software Tools" by Kernighan and Plauger. > > I happened to pull out my copy of that book a week or so ago. It's truly > strange looking at pre-ANSI / pre-POSIX code. I took a class from Webb Miller at UC Santa Barbara in the late 1970s or early 1980s. I don't remember him being much of a teacher, but then I was a total jerk back then so I wasn't much of a student. It was probably my fault. Anyway, I have a copy of this book for sale. It's in excellent condition. It wasn't sold with the software that's printed in the book so you'll have to somehow get the software yourself. Since used copies of this book start at $899.99 on Amazon, I think that $50 plus shipping would be a fair price. (I'll only ship to the US). If you're interested please contact me directly offlist. Jon Forrest P. S. If this book sells it will be the second book I've sold due to mentions on TUHS. ^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-26 18:28 ` arnold 2020-01-26 18:33 ` Adam Thornton 2020-01-26 19:40 ` Jon Forrest @ 2020-01-26 20:08 ` Chet Ramey 2 siblings, 0 replies; 118+ messages in thread From: Chet Ramey @ 2020-01-26 20:08 UTC (permalink / raw) To: arnold, txomsy, tuhs On 1/26/20 1:28 PM, arnold@skeeve.com wrote: > "Jose R. Valverde via TUHS" <tuhs@minnie.tuhs.org> wrote: > >> Talking of editors... >> >> On ancient UNIX, my editor of choice was 's' from Software Tools, its >> main advantage being that it didn't require curses. > > That editor was from "A Software Tools Sampler" by Webb Miller, not > "Software Tools" by Kernighan and Plauger. Before Miller got heavily into genomics and molecular biology research, he was doing work with row-replacement algorithms and optimal sequence calculation and screen updating. I think s is the demonstration vehicle he used for that research, which is probably why it didn't need or use curses. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/ ^ permalink raw reply [flat|nested] 118+ messages in thread
* [TUHS] Screen editors
@ 2020-01-26 20:32 Paul Ruizendaal
2020-01-26 23:14 ` Thomas Paulsen
0 siblings, 1 reply; 118+ messages in thread
From: Paul Ruizendaal @ 2020-01-26 20:32 UTC (permalink / raw)
To: TUHS main list
> > On Jan 26, 2020, at 11:28 AM, arnold at skeeve.com wrote:
> >
> > "Jose R. Valverde via TUHS" <tuhs at minnie.tuhs.org> wrote:
> >
> >> Talking of editors...
> >>
> >> On ancient UNIX, my editor of choice was 's' from Software Tools, its
> >> main advantage being that it didn't require curses.
> >
> > That editor was from "A Software Tools Sampler" by Webb Miller, not
> > "Software Tools" by Kernighan and Plauger.
> Well, that would explain why I couldn’t find it. Do you have softcopy of the editor source? I’d really like a screen editor for v7…. Adam
So do I.
Editor source seems to be here:
https://github.com/udo-munk/s
If you are doing a build for V7, I’d be interested in hearing the results.
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [TUHS] Screen editors 2020-01-26 20:32 Paul Ruizendaal @ 2020-01-26 23:14 ` Thomas Paulsen 0 siblings, 0 replies; 118+ messages in thread From: Thomas Paulsen @ 2020-01-26 23:14 UTC (permalink / raw) To: Paul Ruizendaal; +Cc: tuhs Hello, > Editor source seems to be here: https://github.com/udo-munk/s thanks a lot! Makefile uses clang. So for all gcc users: cp trunk/Makefile ./makefile sed -i 's/clang/gcc/g' makefile cp makefile trunk/ ^ permalink raw reply [flat|nested] 118+ messages in thread
end of thread, other threads:[~2020-02-08 3:46 UTC | newest] Thread overview: 118+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-07 2:31 [TUHS] screen editors Doug McIlroy 2020-01-07 2:37 ` Brantley Coile 2020-01-07 2:38 ` Larry McVoy 2020-01-07 16:30 ` arnold 2020-01-07 16:38 ` Richard Salz 2020-01-07 18:32 ` Dan Cross 2020-01-07 19:14 ` Thomas Paulsen 2020-01-09 5:01 ` Grant Taylor via TUHS 2020-01-10 8:16 ` ricercar 2020-01-08 0:10 ` Jon Steinhart 2020-01-17 22:06 ` Dave Horsfall 2020-01-08 18:30 ` Mary Ann Horton 2020-01-08 21:41 ` Thomas Paulsen 2020-01-09 8:30 ` arnold 2020-01-07 6:19 ` Dave Horsfall 2020-01-07 8:24 ` Thomas Paulsen 2020-01-07 20:44 ` Dave Horsfall 2020-01-08 15:29 ` Steve Mynott 2020-01-08 23:31 ` Dave Horsfall 2020-01-07 9:43 ` ullbeking 2020-01-07 14:53 ` Dan Cross 2020-01-07 19:35 ` Rodrigo G. López 2020-01-08 5:13 ` Mark van Atten 2020-01-07 15:03 ` Clem Cole 2020-01-08 21:43 ` [TUHS] screen editors (FRED) Greg A. Woods 2020-01-09 0:04 ` Dave Horsfall 2020-01-07 15:50 ` [TUHS] screen editors Thomas Paulsen 2020-01-07 20:45 ` Chet Ramey 2020-01-07 21:20 ` Derek Fawcus 2020-01-07 19:57 Doug McIlroy 2020-01-07 20:17 ` Brantley Coile 2020-01-07 20:47 ` Bakul Shah 2020-01-08 7:39 Thomas Paulsen 2020-01-08 15:58 ` Steve Nickolas 2020-01-08 23:41 ` Dave Horsfall 2020-01-09 1:43 ` Nemo Nusquam 2020-01-08 21:49 ` Dave Horsfall 2020-01-08 22:01 ` Clem Cole 2020-01-17 23:38 ` Dave Horsfall 2020-01-18 0:07 ` Ryan Casalino 2020-01-18 23:02 ` greg travis 2020-01-10 8:13 ` markus schnalke 2020-01-10 8:17 ` U'll Be King of the Stars 2020-01-11 19:58 ` markus schnalke 2020-01-11 20:54 ` Derek Fawcus 2020-01-11 21:27 ` Henry Bent 2020-02-04 8:40 ` Sijmen J. Mulder 2020-01-10 15:31 ` Nemo Nusquam 2020-01-10 16:04 ` Clem Cole 2020-01-10 17:10 ` Dan Cross 2020-01-10 17:18 ` Steve Nickolas 2020-01-18 1:55 ` Michael Parson 2020-01-10 15:58 ` Theodore Y. Ts'o 2020-01-08 9:46 Rudi Blom 2020-01-08 14:15 ` Chet Ramey 2020-01-08 15:15 ` Steffen Nurpmeso 2020-01-08 15:42 ` Steve Mynott [not found] ` <68b3d6df-94f6-625d-39bf-6149b4c177c9@andrewnesbit.org> 2020-01-08 20:56 ` Steffen Nurpmeso 2020-01-08 23:21 ` Dave Horsfall 2020-01-09 0:08 ` Warner Losh 2020-01-09 1:28 ` Larry McVoy 2020-01-09 1:40 ` Bakul Shah 2020-01-09 2:04 ` Clem Cole 2020-01-09 2:07 ` Larry McVoy 2020-01-09 2:12 ` Clem Cole 2020-01-09 2:59 ` Bakul Shah 2020-01-09 3:08 ` Larry McVoy 2020-01-09 3:43 ` Bakul Shah 2020-01-09 3:27 ` Mary Ann Horton 2020-01-09 3:34 ` Larry McVoy 2020-01-09 3:49 ` Bakul Shah 2020-01-09 3:55 ` Mary Ann Horton 2020-01-09 5:27 ` Bakul Shah 2020-01-09 4:23 ` Jon Steinhart 2020-01-09 15:54 ` Clem Cole 2020-01-09 17:21 ` Jon Steinhart 2020-01-09 17:30 ` Warner Losh 2020-01-09 17:56 ` Bakul Shah 2020-01-18 2:11 ` Michael Parson 2020-01-09 18:53 ` Larry McVoy 2020-01-09 19:01 ` Jon Steinhart 2020-01-09 19:02 ` Steffen Nurpmeso 2020-01-09 19:19 ` Steffen Nurpmeso 2020-01-09 20:20 ` Mary Ann Horton 2020-01-18 2:06 ` Michael Parson 2020-01-18 3:13 ` Clem Cole 2020-01-18 3:44 ` Kurt H Maier 2020-01-18 15:37 ` Larry McVoy 2020-01-18 22:11 ` markus schnalke 2020-01-09 2:14 ` Greg 'groggy' Lehey 2020-01-09 2:48 ` Chet Ramey 2020-01-09 9:05 ` Thomas Paulsen 2020-01-08 15:11 ` Nemo Nusquam 2020-01-08 15:37 ` Henry Bent 2020-01-18 14:22 ` Michael Parson 2020-01-09 21:46 Norman Wilson 2020-01-09 22:10 ` Brantley Coile [not found] <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> 2020-01-20 14:59 ` [TUHS] Screen editors Jose R. Valverde via TUHS 2020-01-20 16:07 ` Toby Thain 2020-01-20 16:20 ` Larry McVoy 2020-01-31 18:21 ` Jose R. Valverde via TUHS 2020-01-29 22:24 ` Dave Horsfall 2020-01-29 22:33 ` Larry McVoy 2020-02-07 23:05 ` Dave Horsfall 2020-02-07 23:54 ` Richard Salz 2020-02-08 3:11 ` Dave Horsfall 2020-02-08 3:38 ` Ronald Natalie 2020-02-08 0:05 ` Bakul Shah 2020-01-29 23:00 ` Thomas Paulsen 2020-01-26 18:28 ` arnold 2020-01-26 18:33 ` Adam Thornton 2020-01-26 18:36 ` arnold 2020-01-26 18:40 ` arnold 2020-01-26 19:11 ` Adam Thornton 2020-01-26 19:40 ` Jon Forrest 2020-01-26 20:08 ` Chet Ramey 2020-01-26 20:32 Paul Ruizendaal 2020-01-26 23:14 ` Thomas Paulsen
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).