From Newsgroup: alt.sys.pdp11

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).
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn <robin.haberkorn@googlemail.com> writes:

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

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Tue, 12 Nov 2024, Paul Rubin wrote:

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.

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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn <robin.haberkorn@googlemail.com> writes:

On Tue, 12 Nov 2024, Paul Rubin wrote:

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.

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn <robin.haberkorn@googlemail.com> writes:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn <robin.haberkorn@googlemail.com> writes:

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.
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen --- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Rich Alderson <news@alderson.users.panix.com> writes:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Tue, 12 Nov 2024, Rich Alderson wrote:

Robin Haberkorn <robin.haberkorn@googlemail.com> writes:

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

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Tue, 12 Nov 2024, Paul Rubin wrote:

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.

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Tue, 12 Nov 2024, Paul Rubin wrote:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Tue, 12 Nov 2024 20:09:00 -0800, Paul Rubin wrote:

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!
--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn wrote:

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.

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.

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Bob Eager <news0009@eager.cx> writes:

On Tue, 12 Nov 2024 20:09:00 -0800, Paul Rubin wrote:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn <robin.haberkorn@googlemail.com> writes:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Bob Eager <news0009@eager.cx> writes:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn wrote:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn <robin.haberkorn@googlemail.com> writes:

On Tue, 12 Nov 2024, Paul Rubin wrote:

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).
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen --- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Rich Alderson <news@alderson.users.panix.com> writes:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Paul Rubin writes:

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".
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Wed, 13 Nov 2024, Lars Brinkhoff wrote:

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?

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

Corrected, thanks!

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn wrote:

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 "rao14" 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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn wrote:

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

I just sent a separate message.

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

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:

DLW@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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Tue, 12 Nov 2024, Robin Haberkorn wrote:

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 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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024, Lars Brinkhoff wrote:

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:

DLW@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

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024, Lars Brinkhoff wrote:

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?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn wrote:

* 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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn wrote:

You are on GNU Emacs I suppose?

Yes.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn wrote:

Thanks Lars, you are doing a great job!

Thanks!

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.

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024, Lars Brinkhoff wrote:

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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024, Lars Brinkhoff wrote:

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

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!?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Tue, 12 Nov 2024 16:50:59 +0300, Robin Haberkorn wrote:

5<3D ITEST$ L>

Presumably you meant:

5<3D ITESTrEc 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 rCLIrCY, so the command rCLMIrCY (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:

MIrEcrEc

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 (rCLemm eye escape escaperCY, I said), would type rCL$rCY instead of pressing the ESC key, and they would be mystified why it wouldnrCOt work.

It took them two or three attempts before I noticed what they were doing
wrong ...
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 13 Nov 2024 14:36:13 -0500, Rich Alderson wrote:

(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 rCLposerrCY ...
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024 10:34:15 +0300, Robin Haberkorn wrote:

... 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 canrCOt 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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Tue, 12 Nov 2024 20:49:07 +0300, Robin Haberkorn wrote:

On Tue, 12 Nov 2024, Paul Rubin wrote:

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

Looks horrible.
Never seen this coding style.

It comes from Lisp, where it looks equally horrible.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024 10:35:08 +0300, Robin Haberkorn wrote:

On Thu, 14 Nov 2024, Lars Brinkhoff wrote:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024 22:19:26 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

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

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 2024-11-14, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Tue, 12 Nov 2024 20:49:07 +0300, Robin Haberkorn wrote:

On Tue, 12 Nov 2024, Paul Rubin wrote:

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.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024 14:34:56 -0800, John Ames wrote:

On Thu, 14 Nov 2024 22:19:26 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

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 donrCOt need that, either, because its overhead is so low I always leave it running.

And it supports multiple notebooks open at once.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

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

https://www.emacswiki.org/emacs/GuileEmacs
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 2024-11-14 23:11, Lawrence D'Oliveiro wrote:

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.
--
Cheers, Carlos.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Thu, 14 Nov 2024 16:23:17 -0800, Paul Rubin wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

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

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

Oh yeah!

The sooner we get rid of dynamic binding, the happier IrCOll be. ;)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Fri, 15 Nov 2024 01:40:38 +0100, Carlos E.R. wrote:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11


Ar an ceathr|| l|i d|-ag de m|! na Samhain, scr|!obh Lawrence D'Oliveiro:

On Thu, 14 Nov 2024 10:35:08 +0300, Robin Haberkorn wrote:

On Thu, 14 Nov 2024, Lars Brinkhoff wrote:

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!

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

--
rCyAs I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stoutrCO
(C. Moore)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--4092542851-683248921-1731674980=:12521
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 14 Nov 2024, Lawrence D'Oliveiro wrote:

MI=E2=90=9B=E2=90=9B

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 (=E2=80=9C=

emm eye

escape escape=E2=80=9D, I said), would type =E2=80=9C$=E2=80=9D instead o=

f pressing the ESC key,

and they would be mystified why it wouldn=E2=80=99t 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=
=20
am printing Escape and all ^x control characters in reverse (or at least=20
in bold) in order to visually highlight that they are not to be read verbat= im.
--4092542851-683248921-1731674980=:12521--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 2024-11-15 02:56, Lawrence D'Oliveiro wrote:

On Fri, 15 Nov 2024 01:40:38 +0100, Carlos E.R. wrote:

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.

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.
--
Cheers, Carlos.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--4092542851-1840825859-1731677219=:12521
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

On Thu, 14 Nov 2024, Lawrence D'Oliveiro wrote:

On Thu, 14 Nov 2024 10:34:15 +0300, Robin Haberkorn wrote:

... 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=E2=80=99t have everything.=

;)

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

And while I had to extend the language significantly, it grew nicely.=20 Further extensions are planned, like floating point integers as a second=20 numeric data type. Lots of commands are still missing as well - most of=20
that will be adressed in the next major release, which will also move it=20
a bit closer to the DEC TECOs.
A language design problem is also that it's not straight forward to write=
=20
macros that receive string arguments, which will furthermore require to=20
turn macros into something like coroutines, at least if you want=20
immediate execution as we are used to in SciTECO. Not to mention that=20 SciTECO syntax prescribes the number of string arguments, so you will never=
be able=20
to write MqSTRING ARG$. There would have to be ugly E1qFOO$ and=20
E2qFOO$BAR$ hacks. But we might allow @Mq/FOO/ since @ gives enough hints=
=20
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=
=20
and yes, it supports Unicode).
But that's cumbersome. ITS TECO used pointers. Perhaps that's a solution.=
=20
It can be made safe as well, just opaque pointers as a new data type. But=
=20
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.=
=20
You do need additional memory to maintain the undo structures. By modern=20 standards very modest amounts, but considering minimal available RAM sizes=
=20
back then, probably too much.
A few years later, it was already possible as demonstrated Video TECO,=20
which ran on VMS.
--4092542851-1840825859-1731677219=:12521--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--4092542851-398466362-1731678688=:12521
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

On Fri, 15 Nov 2024, Robin Haberkorn wrote:

On Thu, 14 Nov 2024, Lawrence D'Oliveiro wrote:

MI=E2=90=9B=E2=90=9B
=20
This would echo on-screen as

MI$$
=20
and so my fellow students, trying to follow my instructions by looking a=

t

the screen output I was producing instead of what I was saying (=E2=80= =9Cemm eye
escape escape=E2=80=9D, I said), would type =E2=80=9C$=E2=80=9D instead =

of pressing the ESC key,

and they would be mystified why it wouldn=E2=80=99t work.
=20
It took them two or three attempts before I noticed what they were doing
wrong ...
=20

I know that of course. In all of my materials (also in SciTECO itself), I=

am=20

printing Escape and all ^x control characters in reverse (or at least in=

=20

bold) in order to visually highlight that they are not to be read verbati=

m.

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

From Newsgroup: alt.sys.pdp11

Robin Haberkorn <robin.haberkorn@googlemail.com> writes:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Fri, 15 Nov 2024 14:28:22 +0100, Carlos E.R. wrote:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Fri, 15 Nov 2024 16:51:24 +0300, Robin Haberkorn wrote:

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 rCLIrCY for rCLinsert), 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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Fri, 15 Nov 2024 15:49:34 +0300, Robin Haberkorn wrote:

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. rCLCTRL+XrCY with boxes around the rCLCTRLrCY and rCLXrCY to denote those single keys.

You could also take advantage of modern Unicode, as I did, using U+241B
SYMBOL FOR ESCAPE, rCLrEcrCY 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. ;)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Fri, 15 Nov 2024 16:26:55 +0300, Robin Haberkorn wrote:

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 rCLmodern screen editorsrCY I hope you donrCOt mean the vi/vim family ... --- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Fri, 15 Nov 2024 22:13:03 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

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 rCLmodern screen editorsrCY I hope you donrCOt mean the vi/vim family ...

I mean, it's also true of nano.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 2024-11-15 22:58, Lawrence D'Oliveiro wrote:

On Fri, 15 Nov 2024 14:28:22 +0100, Carlos E.R. wrote:

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.
--
Cheers, Carlos.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

"Carlos E.R." <robin_listas@es.invalid> writes:

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).
--
virtualization experience starting Jan1968, online at home since Mar1970
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Fri, 15 Nov 2024, Paul Rubin wrote:

Robin Haberkorn <robin.haberkorn@googlemail.com> writes:

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.

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Sat, 16 Nov 2024 01:18:11 +0100, Carlos E.R. wrote:

I don't think our college was open at nights.

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

Possibly because some staff had to be there watching us.

Security were on patrols. TheyrCOd come by, exchange greetings, see that we were up to no good, and then go away again.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Fri, 15 Nov 2024, Lawrence D'Oliveiro wrote:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 2024-11-16 02:52, Lawrence D'Oliveiro wrote:

On Sat, 16 Nov 2024 01:18:11 +0100, Carlos E.R. wrote:

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.

Possibly because some staff had to be there watching us.

Security were on patrols. TheyrCOd 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.
--
Cheers, Carlos.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--4092542851-1915680382-1731723078=:63587
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

On Fri, 15 Nov 2024, John Ames wrote:

On Fri, 15 Nov 2024 22:13:03 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

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 =E2=80=9Cmodern screen editors=E2=80=9D I hope you don=E2=80=99t 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=20 there were some verbose early line editors, but even ed has a terse=20
command syntax.
--4092542851-1915680382-1731723078=:63587--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--4092542851-1515308833-1731722963=:63587
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

On Fri, 15 Nov 2024, Lawrence D'Oliveiro wrote:

It is conventional in documentation to adopt some distinctive typesetting convention for representing control sequences, e.g. =E2=80=9CCTRL+X=E2=80=

=9D with boxes

around the =E2=80=9CCTRL=E2=80=9D and =E2=80=9CX=E2=80=9D to denote those=

single keys.

You could also take advantage of modern Unicode, as I did, using U+241B SYMBOL FOR ESCAPE, =E2=80=9C=E2=90=9B=E2=80=9D 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=20 control characters has just stuck with me. Perhaps also because I added=20 Unicode only recently.
Furthermoreo, the ^x notation has the advantage of making it relatively=20
easy to see which numeric code it corresponds to. And it gives a printable=
=20
equivalent (caret+x) which is especially important in the context of TECO.=
=20
If you see a reverse ^E, you know, you can write Caret+E as well in most=20 situations.

It might actually be possible to customize these representations - at=20
least for the main text view - in your startup profile (~/.teco_ini). Never= =20
tried that.
--4092542851-1515308833-1731722963=:63587--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Sat, 16 Nov 2024 03:03:07 +0100, Carlos E.R. wrote:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Sat, 16 Nov 2024 05:09:18 +0300, Robin Haberkorn wrote:

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

True, itrCOs a very old tradition, that rCL^rCY 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, rCLrAerCY,
and one of the alternatives names given for that is rCLcontrolrCY. Could there be a convention for using that as a prefix for control characters?

Imagine writing rCLrAeCrCY instead of rCL^CrCY, etc.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Sat, 16 Nov 2024 05:11:15 +0300, Robin Haberkorn wrote:

... even ed has a terse command syntax.

I donrCOt 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 donrCOt 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?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Sat, 16 Nov 2024 05:03:03 +0300, Robin Haberkorn wrote:

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.

ThatrCOs ... 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?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--4092542851-613392362-1731740444=:23622
Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

On Tue, 12 Nov 2024, Rich Alderson wrote:

You should have a look at the actual code of the original EMACS implement=

ation

in TECO. That's possible on real hardware, like the Toad-2 system at SDF=

=2Eorg

where you can get a free account. Otherwise, you're just a poser.

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

For Emacs, I will just use the emacs.tec included in Andy Valencia's TECO.=
=20
I am not going to hold a speech primarily about Emacs. --4092542851-613392362-1731740444=:23622--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--4092542851-1565300115-1731741657=:23622
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

On Sat, 16 Nov 2024, Lawrence D'Oliveiro wrote:

That=E2=80=99s ... impressive. I suupose you track the state of buffer ch=

anges

across loops as well? So when you delete the end of a loop, it has to und=

o

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 ">"=
=20
character that closed the loop.
Therefore, if you rub out ">", the side effects of all but the first loop=
=20
iteration are undone.
Much care is taken that you cannot cause OOM situations and it's=20
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=20
to a so called savepoint file in the same directory before writing out=20
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=20
its original location.
While this restores *exactly* the state of the file at the time of=20
the write-out and it's as efficient as it gets, there are certain=20 disadvantages, so I might change that in the future or at least make it=20 configurable.
I could also unlink the file while keeping a file descriptor alive and=20
then copy the contents upon rubout. At least on UNIX. Theoretically,=20
because it's tricky.

That's right. You cannot even screw up your files on disk by accident.=20
While TECO was accused of being a very dangerous editor, SciTECO is=20
actually safer than most other editors around. You can replace your file=20 contents 10 times and HK it at the end - unless you haven't terminated the=
=20
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=20 command executions (you can pipe buffer contents through external programs=
=20
with EC and SciTECO is not aware what you are doing there). Even=20
clipboard contents are restored on rubout (clipboards are=20
exposed on some platforms as special overloaded Q-Registers).
Also, direct messages to the Scintilla editor widget (ES command) do=20
nothing upon rubout, so people must be careful when using them in=20 interactively executed macros.

Best regards,
Robin
--4092542851-1565300115-1731741657=:23622--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--4092542851-720467657-1731742401=:23622
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

On Sat, 16 Nov 2024, Lawrence D'Oliveiro wrote:

I don=E2=80=99t 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=20
edit text directly. I am considering the key presses to navigate around=20
and invoke special functions also as a language. You don't want to type=20
an S-expression like (move-to-next-line), you want something short like=20 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=20
as well. Sure, it's arguably not the easist language to maintain code in.=
=20
But doing everything in one language has its own beauty. Among other=20
things, every ad-hoc scripting on the command line can - with some=20 discipline - be turned into a macro afterwards. And that very same macro=20
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=20
the UNIX command line.

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

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


--4092542851-720467657-1731742401=:23622--
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Sat, 16 Nov 2024 03:03:07 +0100, Carlos E.R. wrote:

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).
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Robin Haberkorn wrote:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 2024-11-16 04:33, Lawrence D'Oliveiro wrote:

On Sat, 16 Nov 2024 03:03:07 +0100, Carlos E.R. wrote:

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.

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.
--
Cheers, Carlos.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Sat, 16 Nov 2024 10:33:16 +0300, Robin Haberkorn wrote:

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 rCLself-insert-commandrCY command. Keystrokes are just another data type in the ELisp language.

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

What TECO calls a rCLmacrorCY is what other languages call a rCLsubroutinerCY or
rCLfunctionrCY. In Lisp, a rCLmacrorCY is an entirely separate concept -- which it
also has.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Sat, 16 Nov 2024 15:14:44 +0000, Scott Lurndal wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Sat, 16 Nov 2024 03:03:07 +0100, Carlos E.R. wrote:

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.
--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Fri, 15 Nov 2024 15:41:29 -0800, Paul Rubin wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

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.
--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 11/16/2024 4:21 PM, Bob Eager wrote:

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.
--
John H. Reinhardt

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Bob Eager <news0009@eager.cx> writes:

On Sat, 16 Nov 2024 15:14:44 +0000, Scott Lurndal wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Sat, 16 Nov 2024 03:03:07 +0100, Carlos E.R. wrote:

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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Sun, 17 Nov 2024 18:12:20 +0000, Scott Lurndal wrote:

Bob Eager <news0009@eager.cx> writes:

On Sat, 16 Nov 2024 15:14:44 +0000, Scott Lurndal wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Sat, 16 Nov 2024 03:03:07 +0100, Carlos E.R. wrote:

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.
--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

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.

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Stefan Monnier wrote:

Interesting: I only know of one ELisp implementation

Emacs Lisp
Rutgers University Extended Addressing Lisp
CCA Emacs Elisp
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Lars Brinkhoff [2024-11-19 14:26:22] wrote:

Stefan Monnier wrote:

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 2024-11-12 21:55, Rich Alderson wrote:

Robin Haberkorn <robin.haberkorn@googlemail.com> writes:

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.

Nitpick: AMIS is written in PASCAL. :-)

Johnny

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 2024-11-14 15:09, Robin Haberkorn wrote:

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.

The codebases are indeed completely separate.
But there was a committe of sorts I gather, which tried to define a
"standard TECO" at DEC. And that also is connected to that manual.
Not sure when that effort started, and how much work was going on independently on the different implementations before that.

But it seems likely that the standards committe came about because of
the differences in the different implementations. Hmm, it might even
have been a section in the manual that told some of the backstory. Check there?

Johnny

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On Tue, 3 Dec 2024, Johnny Billquist wrote:

The codebases are indeed completely separate.
But there was a committe of sorts I gather, which tried to define a "standard
TECO" at DEC. And that also is connected to that manual.
Not sure when that effort started, and how much work was going on independently on the different implementations before that.

But it seems likely that the standards committe came about because of the differences in the different implementations. Hmm, it might even have been a section in the manual that told some of the backstory. Check there?

The only hint in the manual may be "Copyright (C) 1979, 1985 TECO SIG",
which means that the "TECO Special Interest Group" -- you know that one
that also issued the "Moby Munger" -- was involved.

The manual mentions lots of commands that are specific to one version of
TECO or another. At one point it mentions that only the common subset of
all TECOs should be called "Standard TECO" (p.23). I do not have the impression that this "standard" was designed. My guess is that's just what
all have inherited from the original Bob Clemens DEC port for PDP-6, including some interpollination within DEC.

It's interesting that the defacto "standard" still turned out to be
TECO-11, which is what all "modern" implementations of TECO appear to
clone.
TECO-32 for VMS already added nothing new, right?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Johnny Billquist <bqt@softjar.se> writes:

On 2024-11-12 21:55, Rich Alderson wrote:

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.

Nitpick: AMIS is written in PASCAL. :-)

I occasionally used AMIS on the Dec-10 at the museum, until I switched to using (DEC) TECO all the time on that machine.

An old friend in the 36 bit world used it all the time at the Colorado School of Mines, and is the one who told me that it was written in Algol.
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen --- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Here is a copy of AMIS:

https://github.com/PDP-10/amis/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 2024-12-03 16:55, Robin Haberkorn wrote:

On Tue, 3 Dec 2024, Johnny Billquist wrote:

The codebases are indeed completely separate.
But there was a committe of sorts I gather, which tried to define a
"standard TECO" at DEC. And that also is connected to that manual.
Not sure when that effort started, and how much work was going on
independently on the different implementations before that.

But it seems likely that the standards committe came about because of
the differences in the different implementations. Hmm, it might even
have been a section in the manual that told some of the backstory.
Check there?

The only hint in the manual may be "Copyright (C) 1979, 1985 TECO SIG", which means that the "TECO Special Interest Group" -- you know that one
that also issued the "Moby Munger" -- was involved.

Yes. And looking now, I can't see anything more about the SIG or
standard. Either I saw that somewhere else I can't remember, or maybe I
just imagined it.

The manual mentions lots of commands that are specific to one version of TECO or another. At one point it mentions that only the common subset of
all TECOs should be called "Standard TECO" (p.23). I do not have the impression that this "standard" was designed. My guess is that's just
what all have inherited from the original Bob Clemens DEC port for
PDP-6, including some interpollination within DEC.

That is very possible.

It's interesting that the defacto "standard" still turned out to be
TECO-11, which is what all "modern" implementations of TECO appear to
clone.
TECO-32 for VMS already added nothing new, right?

No. TECO-32 is a superset of TECO-11. Added stuff are for example
backward searching across pages, and the whole callable TECO thing.

Johnny

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 2024-12-03 22:38, Rich Alderson wrote:

Johnny Billquist <bqt@softjar.se> writes:

On 2024-11-12 21:55, Rich Alderson wrote:

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.

Nitpick: AMIS is written in PASCAL. :-)

I occasionally used AMIS on the Dec-10 at the museum, until I switched to using
(DEC) TECO all the time on that machine.

AMIS is pretty decent, I think. Used it a lot back in the day on RSTS/E
and Tops-10.

An old friend in the 36 bit world used it all the time at the Colorado School of Mines, and is the one who told me that it was written in Algol.

Well, he was wrong. I have the sources... :-)

Johnny

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

Johnny Billquist wrote:

AMIS is pretty decent, I think. Used it a lot back in the day on
RSTS/E and Tops-10.

The AMIS source code I know about has a bunch of MACRO-10 files.
It would be interesting to see AMIS for PDP-11 or other machines.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.sys.pdp11

On 2024-12-04 19:36, Lars Brinkhoff wrote:

Johnny Billquist wrote:

AMIS is pretty decent, I think. Used it a lot back in the day on
RSTS/E and Tops-10.

The AMIS source code I know about has a bunch of MACRO-10 files.
It would be interesting to see AMIS for PDP-11 or other machines.

Huh? It's pretty much all Pascal. But the "current" version is most
obviously targeting Tops-10 and VMS. There are "conditionals" in there
for those two.
The RSTS/E port was done from an older version with some limitations.
There are binaries floating around. I do have sources as well, but I
don't know if they are complete. I was for a while trying to get the
whole thing working under RSX, but I eventually decided to abandon that effort, and wrote my own Emacs clone in C, which works both under RSX,
VMS, Unixes of different kinds, and is rather easy to port elsewhere as
well, and which can edit large files on small memory machines.

Johnny

--- Synchronet 3.21d-Linux NewsLink 1.2