* [TUHS] screen editors
@ 2020-01-07 2:31 Doug McIlroy
2020-01-07 2:37 ` Brantley Coile
` (5 more replies)
0 siblings, 6 replies; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ 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; 29+ 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] 29+ messages in thread
end of thread, other threads:[~2020-01-17 22:06 UTC | newest] Thread overview: 29+ 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
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).