Any interesting PDP/TECO photos out there?

[Robin Haberkorn]

Hello everyone,

I am preparing a report about the history of TECO ("From paper tape to
full interactivity: 60 years of TECO evolution").

If you have any kind of interesting pictures, eg. of people actually using
TECO on a PDP (whether CRT or hardcopy terminal), I would be glad to see
them (and use them with your permission).

Does anybody know any kind of authentic early TECO code on the PDP-1?
This is an example reconstructed from Dan Murphy's article ("The
beginnings of TECO"):

5ua (qa; 3d iTEST` l qa-1ua)

The round brackets were replaced by angular brackets in later ASCII
versions. In TECO-11 and all modern variants, you would rather write:

5<3D ITEST$ L>

What was the string termination character back then in the PDP-1 versions?

Here's a TECO "family tree" I reconstructed from various sources:

https://github.com/rhaberkorn/sciteco/wiki/The-other-modern-TECO-implementations#teco-family-tree

I am not counting the Emacs Lisp implementations, as they are probably
(?) only toys. Emacs is in there only because people expect it to be
there. Beginning with Multics Emacs, there is really no more
relationship with TECO.
Dashed arrows show "inspiration" rather than direct code flow.
Any notes and corrections are welcome.

Best regards,
Robin

PS: While I am the author of a TECO dialect (SciTECO), I have never
actually used any of the "historic" implementations. I know The TECO-11 dialect
only from its numerous later C clones (TECOC, TECO-64, TECO for Ultrix).

[Paul Rubin]

Michael Wolf wrote a faithful reimplementation of TECO 23 in C under
PDP-11 Unix in the 1970s, but I don't think it connected to anything in
your diagram. I spent quite a while reading its code and learned a lot
from it. One distinctive thing about its style was Lisp-like layout
of closing curly braces, e.g.

if (x) {foo();
bar++;}}}}

to close several levels of braces. I mention that in case it lets you
know whether it's one you have seen.

[Robin Haberkorn]

Post by Paul Rubin
Michael Wolf wrote a faithful reimplementation of TECO 23 in C under
PDP-11 Unix in the 1970s, but I don't think it connected to anything in
your diagram.

What exactly was TECO 23? TECO-xx is usually a port to the PDP-xx.
Versions were counted per port if I understand correctly.

Post by Paul Rubin
I spent quite a while reading its code and learned a lot
from it. One distinctive thing about its style was Lisp-like layout
of closing curly braces, e.g.
if (x) {foo();
bar++;}}}}
to close several levels of braces. I mention that in case it lets you
know whether it's one you have seen.

Looks horrible.
Never seen this coding style.

[Scott Lurndal]

Post by Robin Haberkorn

Post by Paul Rubin
Michael Wolf wrote a faithful reimplementation of TECO 23 in C under
PDP-11 Unix in the 1970s, but I don't think it connected to anything in
your diagram.

What exactly was TECO 23? TECO-xx is usually a port to the PDP-xx.
Versions were counted per port if I understand correctly.

Post by Paul Rubin
I spent quite a while reading its code and learned a lot
from it. One distinctive thing about its style was Lisp-like layout
of closing curly braces, e.g.
if (x) {foo();
bar++;}}}}
to close several levels of braces. I mention that in case it lets you
know whether it's one you have seen.

Looks horrible.
Never seen this coding style.

Don't much like it myself. In the 1970s, perhaps the programmer
was using punched cards, in which case this type of style might make
some sense to reduce the card count.

[Paul Rubin]

Post by Robin Haberkorn
What exactly was TECO 23? TECO-xx is usually a port to the PDP-xx.
Versions were counted per port if I understand correctly.

I mean DEC TECO version 23 as used under TOPS-10. Yes, that C style was
ugly, but other than that it was very good code. I'm pretty sure it was
inspired by Lisp rather than by punched cards. It's normal to write
Lisp parentheses in that style.

[Lawrence D'Oliveiro]

Post by Robin Haberkorn

Post by Paul Rubin
if (x) {foo();
bar++;}}}}

Looks horrible.
Never seen this coding style.

It comes from Lisp, where it looks equally horrible.

[Kaz Kylheku]

Post by Lawrence D'Oliveiro

Post by Robin Haberkorn

Post by Paul Rubin
if (x) {foo();
bar++;}}}}

Looks horrible.
Never seen this coding style.

It comes from Lisp, where it looks equally horrible.

Says the twit whose way way of writing Lisp makes eyes bleed, and rules
out all possibilities of collaboration.

[Rich Alderson]

I am not counting the Emacs Lisp implementations, as they are probably (?)
only toys. Emacs is in there only because people expect it to be there.
Beginning with Multics Emacs, there is really no more relationship with TECO.

There is no relation between the various Lisp implementations (really ports) of
the Emacs style of editor and the original TECO based implementation, any more
than there is with the Algol implementation AMIS, but they are hardly toys.

PS: While I am the author of a TECO dialect (SciTECO), I have never actually
used any of the "historic" implementations. I know The TECO-11 dialect only
from its numerous later C clones (TECOC, TECO-64, TECO for Ultrix).

You should have a look at the actual code of the original EMACS implementation
in TECO. That's possible on real hardware, like the Toad-2 system at SDF.org
where you can get a free account. Otherwise, you're just a poser.

[Paul Rubin]

Post by Rich Alderson
There is no relation between the various Lisp implementations (really
ports) of the Emacs style of editor and the original TECO based
implementation, any more than there is with the Algol implementation
AMIS, but they are hardly toys.

I think Robin Haberkorn was referring to retro-ish implementations of
TECO that were written in Emacs Lisp, not the other way around. The
claim was that those are probably toy versions of TECO, not that either
the original ITS Emacs or the later GNU Emacs were toy versions of
Emacs.

I think the early versions of TECO were designed for use predominantly
with quite slow printing terminals (10 cps Teletypes or even slower),
and its command set grew around that. You would enter a long editing
command specifying a complicate sequence of edits and cursor motions,
and TECO would execute them without having to noisily and slowly retype
the lines being edited. The Unix editor "ed" was sort of ok with a 30
cps printing terminal and reasonably nice with 120 cps. But it would
have been painful at 10 cps because of retyping the line so often.

TECO of course later grew screen editing features and morphed into an
implementation language for editors, most notably ITS Emacs and its
later Twenex port.

I remember becoming somewhat adept at using TECO under TOPS-10, so the
PDP-11 version that I mentioned was of some interest to me. But I think
not that many people want to edit directly with TECO these days.

[Robin Haberkorn]

Post by Paul Rubin
I think the early versions of TECO were designed for use predominantly
with quite slow printing terminals (10 cps Teletypes or even slower),
and its command set grew around that. You would enter a long editing
command specifying a complicate sequence of edits and cursor motions,
and TECO would execute them without having to noisily and slowly retype
the lines being edited. The Unix editor "ed" was sort of ok with a 30
cps printing terminal and reasonably nice with 120 cps. But it would
have been painful at 10 cps because of retyping the line so often.

From what I read in Dan Murphy's article "The beginnings of TECO", the
early TECO implementation started out as a purely non-interactive tool -
he would punch the script with a Flexowriter and run it on the PDP-1 to
fix up another tape. The reason was that the PDP-1 was in high demand at
the time and you didn't want to occupy it's hardcopy terminal running the
"Expensive Typewriter" for instance.
It also gained some kind of screen mode (CRT support) rather quickly,
but it was stripped again when DEC included it in its distribution. Later
DEC TECOs evolved it again.
From this time on ITS TECO (which was never stripped) and DEC TECO evolved
in different directions.

Post by Paul Rubin
TECO of course later grew screen editing features and morphed into an
implementation language for editors, most notably ITS Emacs and its
later Twenex port.

I guess that the Twenex port ran on a regular DEC TECO, similar to
TECO-11? At least the Standard TECO manual mentions TOPS-20 as well.
I would be interested to include this version of the Emacs macros in my
family tree. So I would branch it off TECO-11.

Best regards,
Robin

[Paul Rubin]

Post by Robin Haberkorn

ITS Emacs and its later Twenex port.

I guess that the Twenex port ran on a regular DEC TECO

This sounds utterly impossible. It has to be that some version of ITS
TECO was ported to TOPS-20 aka Twenex, and Emacs ran on top of it.

[Rich Alderson]

Post by Robin Haberkorn

Post by Paul Rubin
TECO of course later grew screen editing features and morphed into an
implementation language for editors, most notably ITS Emacs and its
later Twenex port.

I guess that the Twenex port ran on a regular DEC TECO, similar to
TECO-11? At least the Standard TECO manual mentions TOPS-20 as well.
I would be interested to include this version of the Emacs macros in my
family tree. So I would branch it off TECO-11.

ITS TECO was ported to TENEX and TOPS-20 (there is no such thing as "Twenex",
no matter what others might think).

There are way too many features missing from TECO-10 to put EMACS on top of it
(and there wasn't a TOPS-20 native port of TECO).

[Paul Rubin]

Post by Rich Alderson
ITS TECO was ported to TENEX and TOPS-20 (there is no such thing as "Twenex",
no matter what others might think).

Twenex was an informal and maybe slightly mocking nickname for the DEC
product officially called TOPS-20. It was inspired by TOPS-20's
resemblance to Tenex, which was a non-DEC alternative OS to DEC's
TOPS-10. I'm sure you're familiar with this, but I'm mentioning it in
case other some readers here aren't.

[Lars Brinkhoff]

Post by Paul Rubin
Twenex was an informal and maybe slightly mocking nickname for the DEC
product officially called TOPS-20.

I get the feeling that this moniker was especially popular at MIT, but
of course it's difficult to gague this today. Especially the AI lab
crowd seemed to almost always use "Twenex" over "TOPS-20".

[Lawrence D'Oliveiro]

(there is no such thing as "Twenex", no matter what others might think).

Lots of us think different.

On top of accusing the OP of being a “poser” ...

[Robin Haberkorn]

Post by Paul Rubin
I remember becoming somewhat adept at using TECO under TOPS-10, so the
PDP-11 version that I mentioned was of some interest to me. But I think
not that many people want to edit directly with TECO these days.

That's exactly why I created SciTECO. It's meant to be "useable these
days" without growing into yet another Emacs-like screen editor.
The basic idea is that the command language is interpreted immediately
with rubout corresponding to Undo. That way you have immediate feedback
and scripting at the same time. Special key macros allow you to navigate
with cursor keys without breaking these principles.
There is syntax highlighting and GUI support.
There are still a lot of features missing that you are used to in modern
editors like code completion and especially LSPs. But it's all planned.

[Bob Eager]

Post by Paul Rubin
I think the early versions of TECO were designed for use predominantly
with quite slow printing terminals (10 cps Teletypes or even slower),
and its command set grew around that. You would enter a long editing
command specifying a complicate sequence of edits and cursor motions,
and TECO would execute them without having to noisily and slowly retype
the lines being edited. The Unix editor "ed" was sort of ok with a 30
cps printing terminal and reasonably nice with 120 cps. But it would
have been painful at 10 cps because of retyping the line so often.

Which was precisely why 'ed' does not print unless asked to. It's also
part of the reason why UNIX commands are silent and short.

I remember using UNIX on a 10cps terminal!

[Scott Lurndal]

Post by Bob Eager

Post by Paul Rubin
I think the early versions of TECO were designed for use predominantly
with quite slow printing terminals (10 cps Teletypes or even slower),
and its command set grew around that. You would enter a long editing
command specifying a complicate sequence of edits and cursor motions,
and TECO would execute them without having to noisily and slowly retype
the lines being edited. The Unix editor "ed" was sort of ok with a 30
cps printing terminal and reasonably nice with 120 cps. But it would
have been painful at 10 cps because of retyping the line so often.

Which was precisely why 'ed' does not print unless asked to. It's also
part of the reason why UNIX commands are silent and short.
I remember using UNIX on a 10cps terminal!

As do I, on an Teletype ASR-33, using an accoustic coupler.

[Paul Rubin]

Post by Bob Eager
Which was precisely why 'ed' does not print unless asked to. It's also
part of the reason why UNIX commands are silent and short.
I remember using UNIX on a 10cps terminal!

'ed' didn't have the idea of a cursor like Teco did. You'd make edits
with s/this/that/ but frequently had to print the line to make sure
changed the right "this", ISTM. It also wasn't scriptable in the sense
that you couldn't easily write a loop to change, say, every third
occurence of "this" to "that".

10 cps terminals were mostly gone by the time I used Unix! I'm sure I
used it that way once or twice, but it was mostly screen terminals, and
30 cps or faster printing terminals.

[Robin Haberkorn]

Post by Rich Alderson

I am not counting the Emacs Lisp implementations, as they are probably (?)
only toys. Emacs is in there only because people expect it to be there.
Beginning with Multics Emacs, there is really no more relationship with TECO.

There is no relation between the various Lisp implementations (really ports) of
the Emacs style of editor and the original TECO based implementation, any more
than there is with the Algol implementation AMIS, but they are hardly toys.

I was talking about the TECO implementations in Emacs Lisp, like this one:
https://github.com/mtk/teco
I don't think it's worth mentioning them in the "family tree".

Post by Rich Alderson

PS: While I am the author of a TECO dialect (SciTECO), I have never actually
used any of the "historic" implementations. I know The TECO-11 dialect only
from its numerous later C clones (TECOC, TECO-64, TECO for Ultrix).

You should have a look at the actual code of the original EMACS implementation
in TECO. That's possible on real hardware, like the Toad-2 system at SDF.org
where you can get a free account. Otherwise, you're just a poser.

Thanks, if I got lots of time, I might do that. Otherwise, it's pretty
pointless. I am not striving to clone any of the historic dialects.

Anyway, wasn't the real Emacs implemented in ITS TECO, so I would have to
emulate ITS instead of TOPS-20?
Lars Brinkhoff had a video doing this.

[Lars Brinkhoff]

Post by Robin Haberkorn
Anyway, wasn't the real Emacs implemented in ITS TECO, so I would have
to emulate ITS instead of TOPS-20?

ITS TECO ran on TOPS-20 and TENEX as well.

[Robin Haberkorn]

Post by Rich Alderson
You should have a look at the actual code of the original EMACS implementation
in TECO. That's possible on real hardware, like the Toad-2 system at SDF.org
where you can get a free account. Otherwise, you're just a poser.

Well, at least I got TECO 36 running on a Soviet âë-0011í PDP-11
compatible home computer on ïó âë-11 (RT-11 compatible). Only in
emulation, although I am considering to buy the real thing as well. That
should be nerdy enough.
Unfortunately, it doesn't support video mode (7:W). So I will still have
to demonstrate that with TECOC on FreeBSD.

For Emacs, I will just use the emacs.tec included in Andy Valencia's TECO.
I am not going to hold a speech primarily about Emacs.

[Lars Brinkhoff]

Post by Robin Haberkorn
If you have any kind of interesting pictures, eg. of people actually
using TECO on a PDP (whether CRT or hardcopy terminal), I would be
glad to see them (and use them with your permission).

I have found a film clip of someone using PDP-6 TECO on a 340 display.
It's probably from around 1967.

Post by Robin Haberkorn
https://github.com/rhaberkorn/sciteco/wiki/The-other-modern-TECO-implementations#teco-family-tree

Emacs never ran on a PDP-6. ITS TECO would be PDP-6/10.

Post by Robin Haberkorn
Beginning with Multics Emacs, there is really no more relationship
with TECO.

I believe EINE was the first Emacs written in Lisp. EINE and SINE
both predate Multics Emacs.

[Robin Haberkorn]

Post by Lars Brinkhoff
I have found a film clip of someone using PDP-6 TECO on a 340 display.
It's probably from around 1967.

Cool. Would you like to share that on your Youtube channel or at least a
frame of it?

Post by Lars Brinkhoff
Emacs never ran on a PDP-6. ITS TECO would be PDP-6/10.

Corrected, thanks!

Post by Lars Brinkhoff

Beginning with Multics Emacs, there is really no more relationship

both predate Multics Emacs.

Interesting. I was reading this "paper":
https://www.multicians.org/mepap.html
It claims that Multics Emacs was created in 1978.
Wikipedia dates EINE to the late 70s. Can we date it more precisely?

Best regards,
Robin

[Lars Brinkhoff]

Post by Robin Haberkorn
Would you like to share that on your Youtube channel or at least a
frame of it?

I just sent a separate message.

Post by Robin Haberkorn
It claims that Multics Emacs was created in 1978.

Yes. There's also an account by Greenberg, documenting the first steps
day by day.
https://github.com/PDP-10/its/blob/master/doc/eak/emacs.lore#L767-L936

Post by Robin Haberkorn
Wikipedia dates EINE to the late 70s. Can we date it more precisely?

Yes, since there are files from PDP-10 backup tapes in MIT archives. We
can follow Weinreb's development of a Lispm text editor. In February
1977 it started to look like Emacs. At first it had no particular name,
but in August 1977 there was this message:

***@MIT-AI 08/08/77 04:26:09
To: (BUG LISPM) at MIT-AI
The Lisp machine editor has now officially been named "EINE",
which stands for EINE Is Not Emacs. (Apologies to Ted Anderson,
the creator of "TINT").

I have some notes about various early Emacsen here:
https://github.com/PDP-10/its/issues/1354

[Robin Haberkorn]

Post by Lars Brinkhoff

Post by Robin Haberkorn
Wikipedia dates EINE to the late 70s. Can we date it more precisely?

Yes, since there are files from PDP-10 backup tapes in MIT archives. We
can follow Weinreb's development of a Lispm text editor. In February
1977 it started to look like Emacs. At first it had no particular name,
To: (BUG LISPM) at MIT-AI
The Lisp machine editor has now officially been named "EINE",
which stands for EINE Is Not Emacs. (Apologies to Ted Anderson,
the creator of "TINT").
https://github.com/PDP-10/its/issues/1354

Thanks Lars, you are doing a great job!
For my presentation, I won't go into great detail on the history of Emacs.
It does not interest me as much and in the end I am trying to sell the
idea that it went into the wrong direction and we should all be using
interactive TECOs nowadays. ;-)
But it was important to put the Multics Emacs vs. EINE question straight.

[Lars Brinkhoff]

Post by Robin Haberkorn
Thanks Lars, you are doing a great job!

Thanks!

Post by Robin Haberkorn
For my presentation, I won't go into great detail on the history of Emacs.

What presentation; where is this going to be?

Are you aware and/or will you include the story of how TECO became the
preferred editor on early DEC platforms? After all, TECO started as an
obscure text editor on an MIT PDP-1; it was just one among many
experimental editors in use across many computers and sites.

The story goes, Bob Clements brought MIT's TECO-6 along when he
installed the Stanford AI lab PDP-6. At this point, TECO-6 was a
standalone program. During the PDP-6 acceptance tests, Clements ported
it over to the PDP-6 Monitor. It then made it back to DEC and was used
on their computers. Apparently many engineers liked it well enough to
port it to newer minicomputers like the PDP-8, 11, etc.

Post by Robin Haberkorn
It does not interest me as much and in the end I am trying to sell the
idea that it went into the wrong direction and we should all be using
interactive TECOs nowadays.

That's great! I prefer Emacs myself, but I think it's good if TECO gets
more attention.

[Lars Brinkhoff]

Post by Lars Brinkhoff
Are you aware and/or will you include the story of how TECO became the
preferred editor on early DEC platforms?

In the words of Clements himself:
http://stuff.offog.org/its/news/1990-clements-sail-teco

Compare Murphy's TECO with TECO-6:
https://bitsavers.org/pdf/mit/rle_pdp1/memos/Murphy_PDP-1_TECO.pdf
https://raw.githubusercontent.com/larsbrinkhoff/its-archives/master/ailab/pdp6-memo-2.pdf

[Robin Haberkorn]

Post by Lars Brinkhoff
https://bitsavers.org/pdf/mit/rle_pdp1/memos/Murphy_PDP-1_TECO.pdf
https://raw.githubusercontent.com/larsbrinkhoff/its-archives/master/ailab/pdp6-memo-2.pdf

Interesting! I wouldn't have thought that any documentation on PDP-1 TECO
has survived. That allows me to correct my example macro. It actually
significantly differs from what Dan Murphy wrote in "The beginnings of
TECO". The termination character was a center dot and loop start/end was
round braces overprinted with center dot. Instead of semicolon, he wrote a
plain colon to evaluate the loop condition. But after `S` you could write
semicolon since it's center dot overprinted with comma!?

[Robin Haberkorn]

Post by Lars Brinkhoff
Are you aware and/or will you include the story of how TECO became the
preferred editor on early DEC platforms? After all, TECO started as an
obscure text editor on an MIT PDP-1; it was just one among many
experimental editors in use across many computers and sites.
The story goes, Bob Clements brought MIT's TECO-6 along when he
installed the Stanford AI lab PDP-6. At this point, TECO-6 was a
standalone program. During the PDP-6 acceptance tests, Clements ported
it over to the PDP-6 Monitor. It then made it back to DEC and was used
on their computers. Apparently many engineers liked it well enough to
port it to newer minicomputers like the PDP-8, 11, etc.

No, I wasn't aware of this story in detail. I just read that Clements
ported and simplified it.

Do you know whether there was any coordination between the TECO-8, TECO-10
and TECO-11 developments? I have the impression they lived their own lifes
until somebody decided to write the "Standard TECO" manual. After all,
these would have been separate codebases as well.

[Lars Brinkhoff]

Post by Robin Haberkorn
Do you know whether there was any coordination between the TECO-8,
TECO-10 and TECO-11 developments?

No, I don't know. I do know the MIT lineage started with PDP-1 TECO,
went on to TECO-6, evolved into ITS TECO, and added technologies
culminating in EMACS. The DEC variants and "Standard TECO" diverged
separately, starting 1966, from a somewhat impovershed TECO-6.

[Lawrence D'Oliveiro]

... in the end I am trying to sell the
idea that it went into the wrong direction and we should all be using
interactive TECOs nowadays. ;-)

Surely Lisp is a much more versatile and extensible language than TECO. I
just wish ELisp had continuations, but you can’t have everything. ;)

Those who grew up on 8-bit micros will tell you the joy of switching the
machine on and be instantly at a prompt from the ROM where you can type
BASIC code -- either a line at a time for immediate execution, or
(prefixed with a line number) to be saved as part of a longer program.

There is a modern system that does this sort of thing in a slicker way, I
think, than any ROM BASIC: that is a Jupyter notebook.

[John Ames]

On Thu, 14 Nov 2024 22:19:26 -0000 (UTC)

Post by Lawrence D'Oliveiro
There is a modern system that does this sort of thing in a slicker
way, I think, than any ROM BASIC: that is a Jupyter notebook.

My C64's zero-to-READY. time is about three seconds. How long does it
take your machine to boot, log in, launch a browser, and load up
Jupyter? ;P

[Lawrence D'Oliveiro]

Post by John Ames
On Thu, 14 Nov 2024 22:19:26 -0000 (UTC)

Post by Lawrence D'Oliveiro
There is a modern system that does this sort of thing in a slicker way,
I think, than any ROM BASIC: that is a Jupyter notebook.

My C64's zero-to-READY. time is about three seconds. How long does it
take your machine to boot, log in, launch a browser, and load up
Jupyter? ;P

My machine is always running. Jupyter can start in three seconds. But I
don’t need that, either, because its overhead is so low I always leave it
running.

And it supports multiple notebooks open at once.

[Paul Rubin]

Post by Lawrence D'Oliveiro
Surely Lisp is a much more versatile and extensible language than TECO. I
just wish ELisp had continuations, but you can’t have everything. ;)

https://www.emacswiki.org/emacs/GuileEmacs

[Lawrence D'Oliveiro]

Post by Paul Rubin

Post by Lawrence D'Oliveiro
Surely Lisp is a much more versatile and extensible language than TECO.
I just wish ELisp had continuations, but you can’t have everything. ;)

https://www.emacswiki.org/emacs/GuileEmacs

Oh yeah!

The sooner we get rid of dynamic binding, the happier I’ll be. ;)

[Robin Haberkorn]

Post by Lawrence D'Oliveiro

... in the end I am trying to sell the
idea that it went into the wrong direction and we should all be using
interactive TECOs nowadays. ;-)

Surely Lisp is a much more versatile and extensible language than TECO. I
just wish ELisp had continuations, but you can’t have everything. ;)

With "interactive TECO" I don't just mean some REPL prompt, even not in
video mode while showing the buffer contents. I mean immediate execution
of source code while you type it and see the results immediately -- the
way it was realized in Video TECO and later by me in SciTECO.
For such an approach, you don't want a verbose language like Lisp. That
wouldn't work of course. You want a terse language like TECO, where the
most frequently used commands are just one or two letters/key presses.
Just like in the modern screen editors. They are also operating on
commands, very short ones, one or two key presses or short key chords. But
they don't show them to you on a command line, and their "language" is not
Turing complete.
So I thought, why not take this lovely language we have -- TECO -- and
turn it into the screen editor language by immediately executing it, thus
abolishing the difference between movement and editing commands and editor
scripting.

And while I had to extend the language significantly, it grew nicely.
Further extensions are planned, like floating point integers as a second
numeric data type. Lots of commands are still missing as well - most of
that will be adressed in the next major release, which will also move it
a bit closer to the DEC TECOs.
A language design problem is also that it's not straight forward to write
macros that receive string arguments, which will furthermore require to
turn macros into something like coroutines, at least if you want
immediate execution as we are used to in SciTECO. Not to mention that
SciTECO syntax prescribes the number of string arguments, so you will never be able
to write MqSTRING ARG$. There would have to be ugly E1qFOO$ and
E2qFOO$BAR$ hacks. But we might allow @Mq/FOO/ since @ gives enough hints
to the parser.
It's also problematic to *return* strings from macros.
Currently, you can push the codepoints on the stack (yes, it's stack based
and yes, it supports Unicode).
But that's cumbersome. ITS TECO used pointers. Perhaps that's a solution.
It can be made safe as well, just opaque pointers as a new data type. But
it requires a significant departure from TECO-11 and its modern clones,
which I still try to be similar to, even if not aiming for compatibility.

Best regards,
Robin

PS: I of course know why back in the 1970s nobody tried anything similar.
You do need additional memory to maintain the undo structures. By modern
standards very modest amounts, but considering minimal available RAM sizes
back then, probably too much.
A few years later, it was already possible as demonstrated Video TECO,
which ran on VMS.

[Paul Rubin]

Post by Robin Haberkorn
And while I had to extend the language significantly, it grew
nicely. Further extensions are planned, like floating point integers

1. Floating point "integers"???

2. TECO is historically important and interesting, and I can sort of
understand wanting to re-implement it as a retrocomputing hack, or maybe
even use it for nerd factor or because you were used to it. But,
extending it seems pretty niche. Does SciTECO have more than one user?

The DEC TECOs were themselves very limited compared to the MIT versions
that I guess culminated in the versions underpinning ITS Emacs.

[Robin Haberkorn]

Post by Paul Rubin

Post by Robin Haberkorn
And while I had to extend the language significantly, it grew
nicely. Further extensions are planned, like floating point integers

1. Floating point "integers"???

"Numbers" I meant. We already have integers obviously. Signed 64-bit
integers to be precise. Floats I would add separately instead of making them the
numeric base type (cf. Lua) - that would IMHO be less intrusive. The
operators would be the same on all numbers, but they will behave
differently depending on the number type (int/float) on the stack.

Post by Paul Rubin
2. TECO is historically important and interesting, and I can sort of
understand wanting to re-implement it as a retrocomputing hack, or maybe
even use it for nerd factor or because you were used to it. But,
extending it seems pretty niche. Does SciTECO have more than one user?

A handful of permanent users perhaps. Hard to know exactly.
It's not super popular obviously. I was hoping for wider adoption, at
least by the nerdier audience. Perhaps it draws more attention once I get the
FreeBSD package into ports (if ever!)
Or once I produce more educational material. People do in fact complain
sometimes, that there aren't any video tutorials.
I guess, it's quite a learning curve.

[Lawrence D'Oliveiro]

Post by Robin Haberkorn
You want a terse language like TECO, where the
most frequently used commands are just one or two letters/key presses.
Just like in the modern screen editors.

By “modern screen editors” I hope you don’t mean the vi/vim family ...

[John Ames]

On Fri, 15 Nov 2024 22:13:03 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by Robin Haberkorn
You want a terse language like TECO, where the
most frequently used commands are just one or two letters/key
presses. Just like in the modern screen editors.

By “modern screen editors” I hope you don’t mean the vi/vim family ...

I mean, it's also true of nano.

[Robin Haberkorn]

Post by John Ames
On Fri, 15 Nov 2024 22:13:03 -0000 (UTC)

Post by Robin Haberkorn
You want a terse language like TECO, where the
most frequently used commands are just one or two letters/key
presses. Just like in the modern screen editors.

By “modern screen editors” I hope you don’t mean the vi/vim family ...

I mean, it's also true of nano.

It's true of *all* modern editors. And historic ones as well. I believe
there were some verbose early line editors, but even ed has a terse
command syntax.

[Lawrence D'Oliveiro]

... even ed has a terse command syntax.

I don’t understand the point of that. Elisp is terse enough as it is,
would you really want a more cryptic version of such custom
programming as

(set-buffer tempbuf)
(insert-buffer-substring-no-properties curbuf beg end)
; Multiline search seems to be troublesome (e.g. slow, stack overflow),
; so find opening and closing tags using separate searches.
(funcall delete-between ; Get rid of commented-out sections.
(lambda () (search-forward "<!--" nil t))
(lambda () (search-forward "-->" nil nil))
)
(dolist (tag '("head" "style" "script"))
; Gobble entire content for these tags, up to and including closing tags
; (luckily they don’t nest).
(funcall delete-between
(lambda () (re-search-forward (concat "<" tag "\\b[^>]*>") nil t))
(lambda () (re-search-forward (concat "</" tag "\\b[^>]*>") nil nil))
)
) ; dolist
(goto-char (point-min))
(perform-replace "<[^>]+>" "" nil t nil)
(setq count (count-words (point-min) (point-max)))
(kill-buffer tempbuf)
(message (format "Words: %d" count))

That is, assuming your editor language can express such things?

[Robin Haberkorn]

I don’t understand the point of that. Elisp is terse enough as it is,
would you really want a more cryptic version of such custom
programming as

Elisp is a scripting language. It's not the "language" you are using to
edit text directly. I am considering the key presses to navigate around
and invoke special functions also as a language. You don't want to type
an S-expression like (move-to-next-line), you want something short like
CTRL+N.

That is, assuming your editor language can express such things?

Not 100% sure what your code does, but it looks like SciTECO could do it
as well. Sure, it's arguably not the easist language to maintain code in.
But doing everything in one language has its own beauty. Among other
things, every ad-hoc scripting on the command line can - with some
discipline - be turned into a macro afterwards. And that very same macro
can be turned into a stand-alone script when using SciTECO with --mung.
And you can use the very same language for sed-like scripts directly on
the UNIX command line.

To get an impression what can currently be done, have a look at my macro
page:
https://github.com/rhaberkorn/sciteco/wiki/Useful-Macros

Or into the lib/ subdirectory. SciTECO currently contains 5000 lines of
TECO code. There are code generators and even a Groff postprocessor
written in SciTECO. So it's already quite powerful.

[Lawrence D'Oliveiro]

Post by Robin Haberkorn
Elisp is a scripting language. It's not the "language" you are using to
edit text directly.

It is, actually. In Emacs, every key has a binding to an ELisp command. So
all you are doing when you type is invoking ELisp commands. Even keys that
insert literal text are just invoking the “self-insert-command” command.
Keystrokes are just another data type in the ELisp language.

Post by Robin Haberkorn
... every ad-hoc scripting on the command line can - with some
discipline - be turned into a macro afterwards.

What TECO calls a “macro” is what other languages call a “subroutine” or
“function”. In Lisp, a “macro” is an entirely separate concept -- which it
also has.

[Lars Brinkhoff]

Post by Lars Brinkhoff

Post by Robin Haberkorn
If you have any kind of interesting pictures, eg. of people actually
using TECO on a PDP (whether CRT or hardcopy terminal), I would be
glad to see them

I have found a film clip of someone using PDP-6 TECO on a 340 display.
It's probably from around 1967.

Maybe Two clips. There isn't much that is known with certainty about
these clips. We know they are from MIT, and that they feature at lot of
AI lab hardware.

The first is at the beginning of
https://projects.csail.mit.edu/video/history/aifilms/43-arm.mp4
The clip shows a display that is commonly used with DEC's Type 340 and
similar devices. We can't be 100% sure it's the one attached to the AI
lab PDP-6, but it seems very likely. The text of the display is very
similar to old ITS source code, which is consistent with the assumed
time frame of the film collection. The use of "↓14" to display a FF
control character is consistent with recovered copies of TECO-6.

The second is one minute into this:
https://projects.csail.mit.edu/video/history/aifilms/75-logo.mp4
I'm even less sure about this one. Someone is typing in text one
character at a time. That's not very TECO-like, but according to some
AI memo from back then, there were experiments in doing so. Next, a
blinking bar cursor appears; this is consistent with TECO-6 displaying
on the 340. Then the text abruptly changes, which is what we would
expect if someone ran a TECO command string.

It's kind of amazing that in this very moment, I'm typing this in a
descendant of the text editor in those clips.

[Robin Haberkorn]

Post by Lars Brinkhoff
It's kind of amazing that in this very moment, I'm typing this in a
descendant of the text editor in those clips.

You are on GNU Emacs I suppose?

[Lars Brinkhoff]

Post by Robin Haberkorn
You are on GNU Emacs I suppose?

Yes.

[Lawrence D'Oliveiro]

Post by Robin Haberkorn

Post by Lars Brinkhoff
It's kind of amazing that in this very moment, I'm typing this in a
descendant of the text editor in those clips.

You are on GNU Emacs I suppose?

Nobody using XEmacs/Lucid Emacs any more? ;)

Seems like it took a while, but GNU Emacs has gradually caught up with,
and surpassed, the fork.

[Aidan Kehoe]

Post by Lawrence D'Oliveiro

Post by Robin Haberkorn

Post by Lars Brinkhoff
It's kind of amazing that in this very moment, I'm typing this in a
descendant of the text editor in those clips.

You are on GNU Emacs I suppose?

Nobody using XEmacs/Lucid Emacs any more? ;)

I am and expect to continue for the next thirty years or so. Would be glad of
development help!

Post by Lawrence D'Oliveiro
Seems like it took a while, but GNU Emacs has gradually caught up with,
and surpassed, the fork.

[Robin Haberkorn]

Post by Robin Haberkorn
https://github.com/rhaberkorn/sciteco/wiki/The-other-modern-TECO-implementations#teco-family-tree

I found a journal called "Moby Munger" - "The official organ of the TECO
Special Interest Group". That's a very interesting read! Google it. There
were at least 3 editions. I didn't know there was a real actual TECO journal!
It contains information about various TECO dialects. It seems everybody
back then "munged" his own dialect or fork. The family tree needs to be extended at least with:

* VTECO on TOPS-20 and TV based on that
* WPI TECO on TOPS-10 based on TECO(-10?) v23
* Stevens TECO based on TECO v23
* XTEC on TOPS-10 and ITS based on Stevens TECO.
That was a real actual TECO compiler!
There is also some info here:
https://sources.vsta.org:7100/teco/file?name=doc/tecolore.txt&ci=tip
I especially find that one interesting because they had to solve the
parseability problem of TECO and they did that differently than
SciTECO. While in SciTECO I fixed the number of string arguments for
each command - which seemed to be least intrusive - XTEC fixed the
number of integer arguments, including macro calls.
* Multics TECO based on early ITS/MIT TECO.
* TEC65 on 6502 CPUs
* Harvard UNIX TECO based on 1973 MIT TECO

And countless others! By the way, hasn't there been any TECO for MS-DOS?

It's interesting to read the "Moby Munger" because it conveys the feeling
of a lively "scene".
We don't have that today. Even SciTECO is only seriously used by a handful
of people. But should it ever "fly" again, we should definitely revive the
"Moby Munger" in one way or another. Maybe as a conference handout or just
as a PDF.

-- Robin

[Lars Brinkhoff]

Post by Robin Haberkorn
* XTEC on TOPS-10 and ITS based on Stevens TECO.
That was a real actual TECO compiler!

This one is present on MIT backups, but Krupansky declined requesting a
copy. There's also a copy on this DECUS tape:
https://pdp-10.trailing-edge.com/decus_20tap4_198111/index.html

[Lawrence D'Oliveiro]

Post by Robin Haberkorn
5<3D ITEST$ L>

Presumably you meant:

5<3D ITEST␛ L>

I remember as a student, a full-screen editor written in TECO, called
VTED, was very popular on our main PDP-11/70 system. Our sysadmin pointed
out that a single VTED user consumed about 10-15% of CPU time. Try scaling
that across 20-30 concurrent users --- you see the problem.

Anyway, hitting CTRL/C (accidentally or otherwise) would exit the full-
screen mode and take you to the TECO prompt. Most users were stuck at this
point, since hitting CTRL/C more times would not get you out of TECO.

The main editor code was stored in the string register named “I”, so the
command “MI” (execute contents of I as macro) would resume full-screen
mode. Of course, you had to end command input with two escapes to tell
TECO to actually execute the command(s) you have entered:

MI␛␛

This would echo on-screen as

MI$$

and so my fellow students, trying to follow my instructions by looking at
the screen output I was producing instead of what I was saying (“emm eye
escape escape”, I said), would type “$” instead of pressing the ESC key,
and they would be mystified why it wouldn’t work.

It took them two or three attempts before I noticed what they were doing
wrong ...

[Carlos E.R.]

Post by Lawrence D'Oliveiro
I remember as a student, a full-screen editor written in TECO, called
VTED, was very popular on our main PDP-11/70 system. Our sysadmin pointed
out that a single VTED user consumed about 10-15% of CPU time. Try scaling
that across 20-30 concurrent users --- you see the problem.

I remember that we students got the VAX on its knees when we were
working on our assignments. We had to type blind on the unresponsive
terminal, and then, after maybe 20 seconds, it would react. It could run
an entire program when it switched to it, though, and fast. It just was
unresponsive to the display/keyboard.

[Lawrence D'Oliveiro]

Post by Carlos E.R.
I remember that we students got the VAX on its knees when we were
working on our assignments. We had to type blind on the unresponsive
terminal, and then, after maybe 20 seconds, it would react. It could run
an entire program when it switched to it, though, and fast. It just was
unresponsive to the display/keyboard.

Was this on VMS?

See, one nice feature of VMS, that I miss on *nix systems, is that the
terminal driver would not echo any user output until the program had
actually read it. So you could tell whether the program you were running
was actually responsive or not.

[Carlos E.R.]

Post by Lawrence D'Oliveiro

Post by Carlos E.R.
I remember that we students got the VAX on its knees when we were
working on our assignments. We had to type blind on the unresponsive
terminal, and then, after maybe 20 seconds, it would react. It could run
an entire program when it switched to it, though, and fast. It just was
unresponsive to the display/keyboard.

Was this on VMS?

Yes.

Post by Lawrence D'Oliveiro
See, one nice feature of VMS, that I miss on *nix systems, is that the
terminal driver would not echo any user output until the program had
actually read it. So you could tell whether the program you were running
was actually responsive or not.

We would count the lines and characters to move the cursor to, then do
the correction blind, then wait for the editor to respond. With luck,
the spelling would be good. Then exit, run the pascal compiler, and wait
again.

We blamed the many instances of the compiler/linker running for the
slowness, we never thought of the editor itself. Or both.

The difficulty of getting computer time pushed me to get my first
computer (paid by my parents, of course). An Amstrad PC1512. I would
never have become proficient with programming using the Uni resources only.

[Lawrence D'Oliveiro]

Post by Carlos E.R.
The difficulty of getting computer time pushed me to get my first
computer (paid by my parents, of course). An Amstrad PC1512. I would
never have become proficient with programming using the Uni resources only.

In my day (slightly earlier than yours, with less access to our own
computers), the way to get more access to the computer lab was after
hours, like in the middle of the night. You could have your choice of
terminals.

[Carlos E.R.]

Post by Lawrence D'Oliveiro

Post by Carlos E.R.
The difficulty of getting computer time pushed me to get my first
computer (paid by my parents, of course). An Amstrad PC1512. I would
never have become proficient with programming using the Uni resources only.

In my day (slightly earlier than yours, with less access to our own
computers), the way to get more access to the computer lab was after
hours, like in the middle of the night. You could have your choice of
terminals.

I don't think our college was open at nights. There was somewhere where
they assigned our time, some paper or something. I don't remember.

Possibly because some staff had to be there watching us.

[Lynn Wheeler]

Post by Carlos E.R.
I don't think our college was open at nights. There was somewhere
where they assigned our time, some paper or something. I don't
remember.
Possibly because some staff had to be there watching us.

IBM, not DEC ... took 2hr intro to fortran/computers and at the end of
the semester the univ hired me to re-implement 1401 MPIO in 360
assembler for 360/30. Univ was getting a 360/67 for tss/360, replacing
709/1401 and got 360/30 replacing 1401 temporarily (until 360/67 was
available).

Univ shutdown datacenter on weekends and I would have the machine room
dedicated all weekend, although 48hrs w/o sleep made monday classes
hard. They gave me a bunch of hardware & software manuals and I got to
design and implement my own monitor, device drivers, interrupt handlers,
error recovery, storage management, etc. and within a few weeks had a
2000 card assembler program.

I quickly learned when I 1st came in sat. morning to clean tape drives
and 1403 printer and disassemble and clean 2540 card reader/punch.
Sometimes when I arrived, the place would be dark, production work had
finished early, and they shut the place down. Sometimes the 360/30
wouldn't power up and reading manuals and trial and error, learned to
put all controllers in CE mode, power on 360/30 and controllers
individually and then take controllers out of CE mode.

the 360/67 came in within a year of taking intro class and univ. hires
me fulltime responsible of os/360 (tss/360 never came to fruition so ran
as 360/65 with os/360, I continue to get the machine room dedicated for
weekends). Student fortran ran under a second on 709 but initially over
a minute with os/360. I install HASP cutting the time in half. I then
start redoing stage2 sysgen to carefully place datasets and PDS members
to optimize arm seek and multi-track search, cutting another 2/3rds to
12.9secs. Student fortran never got better than 709 until i install
Univ. of Waterlook WATFOR.

Then before I graduate, I'm hired fulltime into small group in Boeing
CFO office to help with formation of Boeing Computer Services, place all
dataprocessing in an independent business unit. I thot Renton datacenter
largest in the world, couple hundred million in 360 stuff, 360/65s
arriving faster than they could be installed, boxes constantly staged in
the hallways around the machine room (somebody joked that Boeing was
buying 360/65s like other companies bought keypunches).

[Lawrence D'Oliveiro]

Post by Carlos E.R.
I don't think our college was open at nights.

I remember we could get keys. The labs had their own exterior doors.

Post by Carlos E.R.
Possibly because some staff had to be there watching us.

Security were on patrols. They’d come by, exchange greetings, see that we
were up to no good, and then go away again.

[Carlos E.R.]

Post by Lawrence D'Oliveiro

Post by Carlos E.R.
I don't think our college was open at nights.

I remember we could get keys. The labs had their own exterior doors.

Not ours.

Post by Lawrence D'Oliveiro

Post by Carlos E.R.
Possibly because some staff had to be there watching us.

Security were on patrols. They’d come by, exchange greetings, see that we
were up to no good, and then go away again.

No, it would have to be some staff of the computer department.

Another problem would be to get to the college without a car, as buses
did not run during the night. I didn't hear of anybody doing nights in
there, and I did know some students that were deep into the department.

[Lawrence D'Oliveiro]

Post by Carlos E.R.
Another problem would be to get to the college without a car, as buses
did not run during the night.

Ah, this is why all the choice student accommodation was close to the
University. I recall, from the block of flats I was in, there was a
shortcut across an empty section to get there even quicker.

Though there was this one winter night, I had neglected to check how cold
it was going to get, and I remember going home in the wee hours, shivering
in this thin pullover all the way. Later I found the overnight temperature
had got as low as 2-3°C.

[Scott Lurndal]

Post by Lawrence D'Oliveiro

Post by Carlos E.R.
Another problem would be to get to the college without a car, as buses
did not run during the night.

Though there was this one winter night, I had neglected to check how cold
it was going to get, and I remember going home in the wee hours, shivering
in this thin pullover all the way. Later I found the overnight temperature
had got as low as 2-3°C.

Our computer science building was open 27x7, the coldest day
walking to the office had a wind-chill of -80F. 2C is nothing (it's currently
-2.78C here in california).

[Bob Eager]

Post by Lawrence D'Oliveiro

Post by Carlos E.R.
Another problem would be to get to the college without a car, as buses
did not run during the night.

Though there was this one winter night, I had neglected to check how
cold it was going to get, and I remember going home in the wee hours,
shivering in this thin pullover all the way. Later I found the overnight
temperature had got as low as 2-3°C.

Our computer science building was open 27x7, the coldest day walking to
the office had a wind-chill of -80F. 2C is nothing (it's currently
-2.78C here in california).

My room an campus (for two years) was less than two minutes' walk. It was
actually the nearest room on campus to the computer building.

[John H. Reinhardt]

Post by Bob Eager
My room an campus (for two years) was less than two minutes' walk. It was
actually the nearest room on campus to the computer building.

About the same for me. Living in Deming Basement it was 30 ft to the East exit, down an embankment and in the back door of the Waters Computing Center and through the room once used for drafting classes but where I learned PASCAL and FORTRAN and into the terminal room. Around 2 minutes depending on how fast you slid down the embankment. ;)

The doors locked around 11PM but you could sign up for a waver from the computing center management and be allowed to stay past closing - you just had to stay all night until morning when they opened up again. Once the doors were locked, if you left you could not get back in.

[Scott Lurndal]

Post by Bob Eager

Post by Lawrence D'Oliveiro

Post by Carlos E.R.
Another problem would be to get to the college without a car, as buses
did not run during the night.

Though there was this one winter night, I had neglected to check how
cold it was going to get, and I remember going home in the wee hours,
shivering in this thin pullover all the way. Later I found the overnight
temperature had got as low as 2-3°C.

Our computer science building was open 27x7, the coldest day walking to
the office had a wind-chill of -80F. 2C is nothing (it's currently
-2.78C here in california).

My room an campus (for two years) was less than two minutes' walk. It was
actually the nearest room on campus to the computer building.

I had an apartment just on the campus border, about two blocks
from the CS building. Had an office in the adjacent Statistics
building once I started working part-time for the computer center
starting my sophmore year. Convenient place to leave books during
between classes.

The campus buildings were heated with steam generated at the
university power plant, so there were tunnels connecting all
the buildings on campus. Exploring the tunnel system was a
common passtime in those days (today, I would expect to find
far too many cameras), and with the CS building open 24x7, it
was a convenient starting point to avoid entering through
visible manholes.

[Bob Eager]

Post by Bob Eager

Post by Lawrence D'Oliveiro

Post by Carlos E.R.
Another problem would be to get to the college without a car, as
buses did not run during the night.

Though there was this one winter night, I had neglected to check how
cold it was going to get, and I remember going home in the wee hours,
shivering in this thin pullover all the way. Later I found the
overnight temperature had got as low as 2-3°C.

Our computer science building was open 27x7, the coldest day walking
to the office had a wind-chill of -80F. 2C is nothing (it's
currently -2.78C here in california).

My room an campus (for two years) was less than two minutes' walk. It
was actually the nearest room on campus to the computer building.

I had an apartment just on the campus border, about two blocks from the
CS building. Had an office in the adjacent Statistics building once I
started working part-time for the computer center starting my sophmore
year. Convenient place to leave books during between classes.
The campus buildings were heated with steam generated at the university
power plant, so there were tunnels connecting all the buildings on
campus. Exploring the tunnel system was a common passtime in those
days (today, I would expect to find far too many cameras), and with the
CS building open 24x7, it was a convenient starting point to avoid
entering through visible manholes.

I just measured how far it was. 120 yards.

[Carlos E.R.]

Post by Lawrence D'Oliveiro

Post by Carlos E.R.
Another problem would be to get to the college without a car, as buses
did not run during the night.

Ah, this is why all the choice student accommodation was close to the
University. I recall, from the block of flats I was in, there was a
shortcut across an empty section to get there even quicker.

Most of the university in Madrid was in the north, what was called
"University City". But this college of mine was at the other end of
Madrid, in the south, in one of the radial roads out of the city, a few
kilometres out.

Post by Lawrence D'Oliveiro
Though there was this one winter night, I had neglected to check how cold
it was going to get, and I remember going home in the wee hours, shivering
in this thin pullover all the way. Later I found the overnight temperature
had got as low as 2-3°C.

Heh.

[Robin Haberkorn]

MI␛␛
This would echo on-screen as
MI$$
and so my fellow students, trying to follow my instructions by looking at
the screen output I was producing instead of what I was saying (“emm eye
escape escape”, I said), would type “$” instead of pressing the ESC key,
and they would be mystified why it wouldn’t work.
It took them two or three attempts before I noticed what they were doing
wrong ...

I know that of course. In all of my materials (also in SciTECO itself), I
am printing Escape and all ^x control characters in reverse (or at least
in bold) in order to visually highlight that they are not to be read verbatim.

[Robin Haberkorn]

MI␛␛
This would echo on-screen as
MI$$
and so my fellow students, trying to follow my instructions by looking at
the screen output I was producing instead of what I was saying (“emm eye
escape escape”, I said), would type “$” instead of pressing the ESC key,
and they would be mystified why it wouldn’t work.
It took them two or three attempts before I noticed what they were doing
wrong ...

I know that of course. In all of my materials (also in SciTECO itself), I am
printing Escape and all ^x control characters in reverse (or at least in
bold) in order to visually highlight that they are not to be read verbatim.

By the way, in SciTECO you *can* write MI$$ with dollar signs. Not that
you need any kind of command line termination in order to execute macro
`I` - that would happen immediately the moment you type `I`. But
dollar-dollar would terminate the command line just like Escape-Escape
would. The reason is that I made dollar synonymous to Escape as a regular
command (not as a string terminator). And Escape-Escape is a regular
command in SciTECO instead of an immediate editing construct as it was in
classic TECOs. This also means, you don't have to fear accidentally
terminating a command line when pressing two Escapes in a row in order to
pass an empty string argument. FRfoo$$ is completely safe in SciTECO - the
escapes are part of the FR syntax. Only afterwards, parsing resumes with
regular commands. So to delete with FR and terminate the command line, you
would have to write FRfoo$$$$. But you don't terminate the command line
often. You can edit an entire day without $$. The process will grow
in size, but it's still a fraction of VS Code, I guarantee you that.

[Lawrence D'Oliveiro]

Not that you need any kind of command line termination in order to
execute macro `I` - that would happen immediately the moment you type
`I`.

Ah, I see. The TECO I used on the PDP-11 simply held all your input,
without executing it, until it saw the double-escape, then it ran it all.
This gave you a chance to go back and correct things up to that point.

A single escape was a string terminator (for commands that took strings,
like “I” for “insert), a second escape immediately following caused
command execution.

Fun fact: the second escape had to be entered immediately after the first
one. If you typed something else, then deleted it (back to, but not
including, the first escape), then typed a second escape, it would not
cause command execution.

[Paul Rubin]

Post by Lawrence D'Oliveiro
Ah, I see. The TECO I used on the PDP-11 simply held all your input,
without executing it, until it saw the double-escape, then it ran it all.
This gave you a chance to go back and correct things up to that point.

Yes I'm pretty sure TOPS-10 TECO did that too.

[Bob Eager]

Post by Paul Rubin

Post by Lawrence D'Oliveiro
Ah, I see. The TECO I used on the PDP-11 simply held all your input,
without executing it, until it saw the double-escape, then it ran it all.
This gave you a chance to go back and correct things up to that point.

Yes I'm pretty sure TOPS-10 TECO did that too.

I just discovered that I do have the source of TOPS-10 TECO. Thought I'd
lost it.

[Robin Haberkorn]

Post by Lawrence D'Oliveiro
Ah, I see. The TECO I used on the PDP-11 simply held all your input,
without executing it, until it saw the double-escape, then it ran it all.
This gave you a chance to go back and correct things up to that point.

You can do that with immediate execution (stream parsing) as well. You
just need to track all of the state changes every command could possibly
have on the state of the editor. That's exactly what SciTECO does. You can
always correct your command line since SciTECO can undo
(almost) *everything* including the most destructive changes.
In fact, you can even edit your command line as a buffer by using the {
command and replace the current command line with the new one by using the
} command (possibly recursively). This makes it possible to fix up
commands typed and executed long ago.
SciTECO rubs out up to the point where old and new command lines
differ and then "replays" all characters from the new command line.
This also allows the creation of macros that change the command line - so
called commandline-editing macros.
These can also be bound to (function) keys. This is how SciTECO implements
cursor key movements without relying on an Emacs-like mode or discarding
the current command line. Hard to grasp probably until you've seen it.

[Lawrence D'Oliveiro]

You just need to track all of the state changes every command could
possibly have on the state of the editor. That's exactly what SciTECO
does.

That’s ... impressive. I suupose you track the state of buffer changes
across loops as well? So when you delete the end of a loop, it has to undo
it all back to the start of that, ready to run all the iterations again?

Hmmm ... what happens to any file output done in the meantime?

[Robin Haberkorn]

That’s ... impressive. I suupose you track the state of buffer changes
across loops as well? So when you delete the end of a loop, it has to undo
it all back to the start of that, ready to run all the iterations again?

Sure, undo tokens get associated with command line positions.
When you close a loop, all further undo tokens will be "glued" to the ">"
character that closed the loop.
Therefore, if you rub out ">", the side effects of all but the first loop
iteration are undone.
Much care is taken that you cannot cause OOM situations and it's
always possible to interrupt loops and blocking operations by pressing CTRL+C.

Hmmm ... what happens to any file output done in the meantime?

When you save a file, SciTECO currently moves/renames the existing file
to a so called savepoint file in the same directory before writing out
the new state of the file.
This savepoint file is "owned" by the corresponding undo token.
In order to undo the save (on rubout), it simply moves the file back to
its original location.
While this restores *exactly* the state of the file at the time of
the write-out and it's as efficient as it gets, there are certain
disadvantages, so I might change that in the future or at least make it
configurable.
I could also unlink the file while keeping a file descriptor alive and
then copy the contents upon rubout. At least on UNIX. Theoretically,
because it's tricky.

That's right. You cannot even screw up your files on disk by accident.
While TECO was accused of being a very dangerous editor, SciTECO is
actually safer than most other editors around. You can replace your file
contents 10 times and HK it at the end - unless you haven't terminated the
command line, you can always rub out all destructive changes later on!

The only things SciTECO does not undo are the side effects of external
command executions (you can pipe buffer contents through external programs
with EC and SciTECO is not aware what you are doing there). Even
clipboard contents are restored on rubout (clipboards are
exposed on some platforms as special overloaded Q-Registers).
Also, direct messages to the Scintilla editor widget (ES command) do
nothing upon rubout, so people must be careful when using them in
interactively executed macros.

Best regards,
Robin

[Lawrence D'Oliveiro]

Post by Robin Haberkorn
In all of my materials (also in SciTECO itself),
I am printing Escape and all ^x control characters in reverse (or at
least in bold) in order to visually highlight that they are not to be
read verbatim.

It is conventional in documentation to adopt some distinctive typesetting
convention for representing control sequences, e.g. “CTRL+X” with boxes
around the “CTRL” and “X” to denote those single keys.

You could also take advantage of modern Unicode, as I did, using U+241B
SYMBOL FOR ESCAPE, “␛” for ESC. There is a whole set of picture
representations for the ASCII control characters, including space and
delete, in the block from 0x2400 onwards. But for most of them, users
would be unlikely to remember which alphanumeric key they corresponded
to. ;)

[Robin Haberkorn]

Post by Lawrence D'Oliveiro
It is conventional in documentation to adopt some distinctive typesetting
convention for representing control sequences, e.g. “CTRL+X” with boxes
around the “CTRL” and “X” to denote those single keys.
You could also take advantage of modern Unicode, as I did, using U+241B
SYMBOL FOR ESCAPE, “␛” for ESC. There is a whole set of picture
representations for the ASCII control characters, including space and
delete, in the block from 0x2400 onwards. But for most of them, users
would be unlikely to remember which alphanumeric key they corresponded
to. ;)

This could be easily done of course, but the traditional TECO echoing of
control characters has just stuck with me. Perhaps also because I added
Unicode only recently.
Furthermoreo, the ^x notation has the advantage of making it relatively
easy to see which numeric code it corresponds to. And it gives a printable
equivalent (caret+x) which is especially important in the context of TECO.
If you see a reverse ^E, you know, you can write Caret+E as well in most
situations.

It might actually be possible to customize these representations - at
least for the main text view - in your startup profile (~/.teco_ini). Never
tried that.

[Lawrence D'Oliveiro]

... the traditional TECO echoing of control characters has just stuck
with me.

True, it’s a very old tradition, that “^” followed by an alphanumeric. Did
it originate on DEC systems? Probably, like so many things terminal-
related.

Though, checking current Unicode charts, there is U+2388 HELM SYMBOL, “⎈”,
and one of the alternatives names given for that is “control”. Could there
be a convention for using that as a prefix for control characters?

Imagine writing “⎈C” instead of “^C”, etc.

[Stefan Monnier]

Post by Robin Haberkorn
I am not counting the Emacs Lisp implementations,

Interesting: I only know of one ELisp implementation
(https://github.com/mtk/teco/). I'd be interested if you
have pointers to other implementations.

Post by Robin Haberkorn
as they are probably (?) only toys.

I don't know anyone who actually used it, but the description of changes
in the different "versions" suggests that it was definitely used by
some people. The README.md in the above Git repo suggests that the
current "maintainer" also uses it occasionally.


Stefan

[Lars Brinkhoff]

Post by Stefan Monnier
Interesting: I only know of one ELisp implementation

Emacs Lisp
Rutgers University Extended Addressing Lisp
CCA Emacs Elisp

[Stefan Monnier]

Post by Robin Haberkorn

Post by Stefan Monnier
Interesting: I only know of one ELisp implementation

Emacs Lisp
Rutgers University Extended Addressing Lisp
CCA Emacs Elisp

I was talking about ELisp implementation ... of TECO.


Stefan