Any interesting PDP/TECO photos out there?

[Lawrence D'Oliveiro]

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

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

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

[Lynn Wheeler]

Post by Lynn Wheeler
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 Waterloo WATFOR.

whole still at univ, CSC came out to install CP67 (3rd after CSC itself
and MIT Lincoln Labs) ... and I mostly played with it during my weekend
dedicated time. Initially I spent most of the time rewritting CP67
pathlengths to improve OS/360 running in virtual machine, OS/360 test
stream ran 322secs on real machine, but initially 856secs in virtual
machine (534secs CP67 CPU). After a couple months I got CP67 CPU down to
113secs (from 534) ... and was asked to attend CP67 "official"
announcement at spring '68 SHARE meeting in Houston ... where I gave
presentations on both (earlier) OS/360 optimization and (more recent)
CP67 optimization work (running OS/360 invirtual machine).

I then rewrite I/O, ordered arm seek queuing (in place of FIFO) and
multiple 4k page transfers I/O, optimized transfers/revolution for 2314
(disk) and 2301 (drum, from 70-80/sec to 270/sec peak), optimized page
replacement, dynamic adaptive resource management and scheduling (for
multi-user CMS interactive).

CP67 initially had 1052&2741 terminal support with automagic terminal
type identification. Univ. had some asciii (mostly tty33 ... but some
tty35) ... so added tty/ascii support (including integrated with
terminal type identification). I then wanted to have single dail-in
phone number for all terminal types ("hunt group"). Didn't quiet work,
since IBM telecommunication controller had taken short cut and
hard-wired terminal line speed.

This kicks off univ clone telecommunication project, building 360
channel interface board for Interdata/3 programmed to simulate IBM
controller with the addition of being able to do dynamic line
speed. Later it was upgraded with Interdata/4 for channel interface and
cluster of Interdata/3s for line(/port) interfaces.

was then sold as 360 clone controller by Interdata and later
Perkin-Elmer, and four of us get written up for (some part of) IBM clone
controller business.
https://en.wikipedia.org/wiki/Interdata
https://en.wikipedia.org/wiki/Perkin-Elmer#Computer_Systems_Division

other ascii info ... originally 360 was suppose to be ascii machine, but
ascii unit record was ready yet, so it was "temporary" going to be
EBCDIC with old BCD machines. "Biggest Computer Goof Ever":
https://web.archive.org/web/20180513184025/http://www.bobbemer.com/P-BIT.HTM

other history
https://en.wikipedia.org/wiki/Cambridge_Scientific_Center
https://en.wikipedia.org/wiki/History_of_CP/CMS

above (currently) has confusion about Future System and Gene
Amdahl. Amdahl had won the battle to make ACS, 360 compatible ... and
then leaves IBM when ACS/360 was killed
https://people.computing.clemson.edu/~mark/acs_end.html
... before Future System started.
https://en.wikipedia.org/wiki/IBM_Future_Systems_project
https://en.wikipedia.org/wiki/History_of_CP/CMS#Historical_notes

FS was completely different than 370 and was going to completely replace
370, during FS, 370 projects were being killed off, the lack of new 370
products during the FS period is credited with giving clone 370 makers
(including Amdahl) their market foothold. When FS finally implodes there
is mad rush to get stuff back into the 370 product pipelines, including
quick and dirty 3033&3081 efforts in parallel ... more information
http://www.jfsowa.com/computer/memo125.htm

A decade ago, I was asked to track down the executive decision to add
virtual memory to all 370s and found staff member reporting to the
executive. Basically the (OS/360) MVT storage management was so bad that
regions typically had to be specified four times later than used ... so
that standard 1mbyte 370/165 only ran four regions concurrently,
insufficient to keep the system busy and justified.

Mapping MVT to 16mbyte virtual memory (VS2/SVS) allowed concurrent
regions to be increased by factor of four times (with cap of 15 with
4bit storage protect keys, unique key for each concurrent running
region) with little or no paging (sort of like running MVT in a CP67
16mbyte virtual machine).

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