Comment by Animats | Hacker News Reader

Comment by Animats | Hacker News Reader

Because EMACS wasn't developed for the PDP-11. It came from the MIT ITS and Stanford SAIL systems, which had real "meta" keys.[1] Those keyboards also had a "Top" key, an additional shift for extra symbols on top of the keys. See "MIT Space Cadet Keyboard", and Symbolics keyboards.

The control-S/control-Q flow control only worked on UNIX in "line mode", which also did backspace and such. VI turned that off and ran in raw mode. Before BSD, UNIX mostly ran in line mode. The TCP/IP implementation we used, a heavily modified 3COM UNET, predated BSD networking. It normally ran in "line mode", and when running VI remotely, VI switched the pseudo-terminal to "raw mode", which caused the Telnet connection to send the options DON'T ECHO[2] and DO SUPPRESS GO AHEAD.[3] The connection was now transparent to special characters. This was necessary on the rather laggy links of the time. Exiting VI restored line mode.

If VI crashed, or you killed it, or, when job control came in, you switched tasks, you were stuck in raw mode, and had to reset the terminal session by typing "stty saneLF". You actually had to type LF, because CR->LF translation was suppressed in that mode.

BSD didn't bother with this, and ran terminals in remote echo mode all the time, which required lower lag connections. Berkeley was mostly IP over Ethernet at the time, without much long-haul, so that worked for them.

[1] http://xahlee.info/kbd/iold51593/SAIL_keyboard_96232.jpg [2] https://tools.ietf.org/html/rfc857 [3] https://tools.ietf.org/html/rfc858

Just to not leave a misimpression: Emacs (and TECO) never ran on the Stanford Sail machine (which ran the Waits OS); The "E" editor that was native to Sail/Waits used combinations of the Meta and Control keys for commands, which perhaps helped inspire their use in Emacs (written originally ITS at MIT).

It's worth noting that at Sail, the Meta and Control keys simply sent extra "bucky" bits on top of the 7-bit character code, resulting in a 9-bit input. And the actual ESC key was intercepted by the Waits for special commands from the user, and was never delivered to user-land programs (ESC-H tells the OS to hide your screen from others; ESC-I asks the OS to send an interrupt signal to your program; etc). The octal location 033, where ESC lives in Ascii, was instead used for the character "not-equals" on Sail; similarly, most of the other locations in the range 001-037 were used for other special characters that aren't in Ascii, and all were typically generated with a Top key-combination press. The whole notion of Control automatically stripping off the high-order bits of a character was foreign.

> octal location 033

of course this predates the invention of hex, or at least the modern conventional notation for it

Pre-PDP11, DEC had machines with 12, 18, and 36 bit words. Those are all multiples of 3, so octal was more natural. (For the 16-bit PDP11, the instruction format made octal natural.)

This was all well before my time, but I find it fascinating.

One thing I've noticed in going over the early Unix versions is that the Bell Labs people didn't care for VT100s at all and Research Unix has practically no support for video terminals. They probably didn't jump straight from the Teletype to the Blit, but their software sure did. On the other hand, BSD took full advantage of the ADM-3A from day one, and termcap/curses expanded to support each of the VT series as they were released.

>you were stuck in raw mode, and had to reset the terminal session

Man I forgot about all this terminal wrangling stuff. Thanks for the memories!

echo "<ctrl-v><ESC>c"

...is still in my memory.

> You actually had to type LF,

to be clear, this means ctrl-j. I still have to use it very occasionally.

Actually, an LF before `stty sane` is advisable too.

Reply on news.ycombinator.com