The Unix Heritage Society mailing list
 help / color / Atom feed
* [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: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  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  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
  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  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  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  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 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 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-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  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-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 (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
  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 (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 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-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-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-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-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: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-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-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-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-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-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-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-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-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-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

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

* 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: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: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: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: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-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-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 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
       [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-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-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-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-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-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  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-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  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-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-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-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-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: 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-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-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 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 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  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-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  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-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-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

* 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 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 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 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 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 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 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: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 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  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  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-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  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: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: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  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  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  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  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: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  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: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: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  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-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-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  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-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-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 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 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  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
       [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  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: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

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

end of thread, back to index

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

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git