[TUHS] screen editors

[TUHS] screen editors

[Doug McIlroy]

> 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

Re: [TUHS] screen editors

[Brantley Coile]

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

Re: [TUHS] screen editors

[Larry McVoy]

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.

Re: [TUHS] screen editors

[Dave Horsfall]

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

Re: [TUHS] screen editors

[Thomas Paulsen]

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

Re: [TUHS] screen editors

[ullbeking]

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

Re: [TUHS] screen editors

[Dan Cross]

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

Re: [TUHS] screen editors

[Clem Cole]

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

Re: [TUHS] screen editors

[Thomas Paulsen]

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

Re: [TUHS] screen editors

[arnold]

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

Re: [TUHS] screen editors

[Richard Salz]

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

Re: [TUHS] screen editors

[Dan Cross]

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

Re: [TUHS] screen editors

[Thomas Paulsen]

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

Re: [TUHS] screen editors

[Rodrigo G. López]

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

Re: [TUHS] screen editors

[Dave Horsfall]

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

Re: [TUHS] screen editors

[Chet Ramey]

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/

Re: [TUHS] screen editors

[Derek Fawcus]

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

Re: [TUHS] screen editors

[Jon Steinhart]

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

Re: [TUHS] screen editors

[Mark van Atten]

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.

Re: [TUHS] screen editors

[Steve Mynott]

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

Re: [TUHS] screen editors

[Mary Ann Horton]

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

Re: [TUHS] screen editors

[Thomas Paulsen]

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

Re: [TUHS] screen editors (FRED)

[Greg A. Woods]

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

Re: [TUHS] screen editors

[Dave Horsfall]

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

Re: [TUHS] screen editors (FRED)

[Dave Horsfall]

I'm surprised that no-one has mentioned "F*cking Ripper of an EDitor" yet, 
or was it UNSW-only?

-- Dave

Re: [TUHS] screen editors

[Grant Taylor via 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 --]

Re: [TUHS] screen editors

[arnold]

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

Re: [TUHS] screen editors

[ricercar]

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

Re: [TUHS] screen editors

[Dave Horsfall]

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