Screen editing and where it should go....

[Chris Torek]

>In article <8263 at brl-smoke.ARPA> gwyn at brl-smoke.ARPA (Doug Gwyn) writes:
>>Terminal input editing belongs where the input is being done,
>>namely the terminal.

>In article <1188 at ficc.UUCP> peter at ficc.UUCP (Peter da Silva) answers:
>How IBM mainframe of you. How about putting file editing in the terminal
>as well?

In article <12139 at duke.cs.duke.edu> crm at romeo.cs.duke.edu (Charlie Martin)
notes:
>Actually, the screen editor I liked best of all editors ever was a
>probably bootlegged HP editor on the HP1000 (who remembers *that*
>machine!).  [description elided]

I used a similar editor on an HP 3060A board test system, which used an
HP 9825A `desktop calculator' (a bizarre machine: built in the mid
1970s or so, it used a 16-bit SOS [Silicon on Sapphire, for us software
types :-) ] cpu; the unit ran about $10K, in mid-70s dollars).  I
really liked that editor, but then that would be natural, since I
wrote it myself.

(The 9825A ran something called HPL, a curious mix of BASIC and FORTRAN
and APL.  One of its unusual features was that, to speed interpretation,
the input section would delete unnecessary parentheses from expressions.
Hence if you wrote

	A <- (B C) + (1 + rE) * 4

it would edit this to

	A <- B C + (1 + rE) * 4

The <- here represents a left-pointing arrow.  All variables were in
uppercase save the special `r' variables, which were a dynamic array of
sorts.  r variables were created when mentioned; the syntax was r<expr>,
and hence one could use another r variable as an indirect, and write
expressions like

	A <- rr0 r1 + r(r(rE+2)+3)

The adjacent `rr0 r1' implied multiplication.)

Ah, the joys of summer jobs in high school....  (And a lesson in
spotting nerds: other kids mowed lawns or delivered papers; I
programmed $100K systems test machines :-) .)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris