3 ms·

Yea, I walked into the SOS room day one of my degree and so learned SOS and Pascal instead of LISP and TECO. I do sometimes think I chose the wrong room. But yo

by ggm 2y ago

Yea, I walked into the SOS room day one of my degree and so learned SOS and Pascal instead of LISP and TECO. I do sometimes think I chose the wrong room. But your point about the point is well made, I think the DEC-10 TECO had a way to draw the current line and show where the point was, but it was very inferior to have to do it. Like chess wizards you're meant to carry an image of the code in your head at all times. I tried teco, couldn't entirely cope. SOS led naturally to ed in due course. I did learn emacs, But never really took to it. Now, I run my daily work log in org mode and do nothing else in it, but it is very good as a massively over-engineered multi-window table editor. Charles Forsyth (York) wrote a macro for ed which took the point, redrew the 24 line vt00 display to show the lines around it (12 above 11 below) and put you back where you were. He said it made ed as good as vi, and on the baudrate of the day who am I to disagree?

whartung 2y ago
On the Cyber running NOS, we had XEDIT. And similar to your story, I routinely dumped 10 lines of context after each change. Whatever that command was, was hard coded into muscle memory to the point it was mostly automatic. The other nice feature was that you could do quick in place edits from the command line. Combination of ed and sed. Another aspect that impacted TECO on the PDP was the concept of paging the file in. The machine was limited enough that you as a user were responsible for swapping parts of the buffer in and out, which, while usable, was not a good user experience. When loading a large file TECO/vtedit would prompt “loading file xxx.yyy slowly”. And it was. In the labs, my friend and I would commandeer multiple terminals, with one of them being our file loaded in the editor. We’d constantly write the file out, but never exit. And by “large file”, I’m talking a 35K byte source file. It was a different time, to be sure.
kragen 2y ago
if you mean unix ed, ed doesn't have macros. maybe it was ex?
TheOtherHobbes 2y ago
One of the reasons TECO worked as it did is because baudrate limitations were unimaginable by today's standards. Text would appear character by character, so it would take a good few seconds to show 24(!) lines of code.

by ggm 2y ago

whartung 2y ago

On the Cyber running NOS, we had XEDIT. And similar to your story, I routinely dumped 10 lines of context after each change. Whatever that command was, was hard coded into muscle memory to the point it was mostly automatic. The other nice feature was that you could do quick in place edits from the command line. Combination of ed and sed. Another aspect that impacted TECO on the PDP was the concept of paging the file in. The machine was limited enough that you as a user were responsible for swapping parts of the buffer in and out, which, while usable, was not a good user experience. When loading a large file TECO/vtedit would prompt “loading file xxx.yyy slowly”. And it was. In the labs, my friend and I would commandeer multiple terminals, with one of them being our file loaded in the editor. We’d constantly write the file out, but never exit. And by “large file”, I’m talking a 35K byte source file. It was a different time, to be sure.

kragen 2y ago

if you mean unix ed, ed doesn't have macros. maybe it was ex?

TheOtherHobbes 2y ago

One of the reasons TECO worked as it did is because baudrate limitations were unimaginable by today's standards. Text would appear character by character, so it would take a good few seconds to show 24(!) lines of code.