6 ms·

On FreeBSD /usr/ports/editors/teco still works if you want to try your name and $ to see what awesome edit happens (my name starting with g I think means its g(

by ggm 2y ago

On FreeBSD /usr/ports/editors/teco still works if you want to try your name and $ to see what awesome edit happens (my name starting with g I think means its g(lobally) applied) Interesting to see '76 email formats had To: and CC: but not Subject: and Date: info was rolled into what now we might call the Envelope, projected into the header. I used EMAS and Vax/VMS based email in '79 which was sufficiently second-system to have a standard to implement against and Type:Value was in, with Date: and Subject:

Blackthorn 2y ago
Also if anyone wants to dip your toes into teco, we're sufficiently full circle that there's an emacs implementation of it you can use! https://github.com/mtk/teco https://github.com/mtk/teco
- ggm 2y ago
  It's emulated turtles all the way down.
- gumby 2y ago
  I used to use meta-altmode (a non-ascii key on the KTV) to enter the minibuffer (note: not the region under the mode line) that accepted raw TECO and interpreted it directly. And to be more extreme: you could actually write small assembly routines and run them in the registers (the first 20 addresses in the PDP-10 address space were the registers — super fast bc they were implemented with semiconductors rather than core!). That was hardcore and I only did it once or twice, just for fun.
  - Blackthorn 2y ago
    I'd love to learn enough TECO to be able to do exactly that with Emacs's teco mode. I do it with ex (through viper) all the time. At this point I wonder if my brain has ossified to the point that it's incapable of learning a new language syntax.
    - gumby 2y ago
      Have you ever seen TECO? It barely has syntax — it looks like line noise. Would you want to run the local assembly language (x86 or ARM) or are you thinking of also doing this with a PDP-10 emulator? Either way, this would be rather cool.
- anyfoo 2y ago
  It’s a bit trite to call out the next nesting step, but in this particular case I’d really like to see original TECO emacs running in modern emacs TECO.
whartung 2y ago
My Pooh brain, especially today, goes into cognitive overload trying to keep track of an invisible point in a character based text editor. Line editors are much less of a problem. In these I typically did not insert text in the middle of a line, I simply changed/substituted text in the middle of the line. This helps maintain context in contrast to moving a point around. Fortunately, my TECO exposure was mostly tempered through VTedit, a screen oriented macro set for TECO on the PDP. Couldn’t escape it completely, but it helped reduce the load in my challenged, tiny brain. By the time I moved to VMS, they had switched to EDT. Much more accessible.
- 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.

by ggm 2y ago

Blackthorn 2y ago

Also if anyone wants to dip your toes into teco, we're sufficiently full circle that there's an emacs implementation of it you can use! https://github.com/mtk/teco https://github.com/mtk/teco

ggm 2y ago
It's emulated turtles all the way down.
gumby 2y ago
I used to use meta-altmode (a non-ascii key on the KTV) to enter the minibuffer (note: not the region under the mode line) that accepted raw TECO and interpreted it directly. And to be more extreme: you could actually write small assembly routines and run them in the registers (the first 20 addresses in the PDP-10 address space were the registers — super fast bc they were implemented with semiconductors rather than core!). That was hardcore and I only did it once or twice, just for fun.
- Blackthorn 2y ago
  I'd love to learn enough TECO to be able to do exactly that with Emacs's teco mode. I do it with ex (through viper) all the time. At this point I wonder if my brain has ossified to the point that it's incapable of learning a new language syntax.
  - gumby 2y ago
    Have you ever seen TECO? It barely has syntax — it looks like line noise. Would you want to run the local assembly language (x86 or ARM) or are you thinking of also doing this with a PDP-10 emulator? Either way, this would be rather cool.
anyfoo 2y ago
It’s a bit trite to call out the next nesting step, but in this particular case I’d really like to see original TECO emacs running in modern emacs TECO.

whartung 2y ago

My Pooh brain, especially today, goes into cognitive overload trying to keep track of an invisible point in a character based text editor. Line editors are much less of a problem. In these I typically did not insert text in the middle of a line, I simply changed/substituted text in the middle of the line. This helps maintain context in contrast to moving a point around. Fortunately, my TECO exposure was mostly tempered through VTedit, a screen oriented macro set for TECO on the PDP. Couldn’t escape it completely, but it helped reduce the load in my challenged, tiny brain. By the time I moved to VMS, they had switched to EDT. Much more accessible.

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.