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.
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.
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.
Bill Joy used an ADM 3A[1] terminal, and looking at the keyboard layout explains vi's key mappings almost entirely.
There are arrow keys printed on HJKL (accessed via control), escape is left of Q, control is left of A, and colon has a dedicated key rather than being shift+semicolon.
Another tidbit is that the home key is also used for tilde, which explains its association with the home directory.
Well, it's :* and ;+ and so on, along with the now-unusual shifted number row: a bit-paired keyboard¹, matching ASCII, which was the practical thing to do when your terminal was hard-wired.
It does seem like an additional reason, but I'm convinced tabs were (are?) disliked primarily for historical and technological reasons. Historically the tab key worked with a tab stop; there's always friction when you switch paradigms. Technologically, accommodating a variable width non-printing character on an 80x25 character-mapped display for no particular reason must have seemed both gratuitous and wasteful when you consider the typical hardware of the time (monochrome terminals, CPUs on the order of 1-50 MHz, 1-5 MB RAM, < 1 MB ROM, etc).
> disliked primarily for historical and technological reasons
Huh? AFAIU, all the historical source code uses tabs for indentation. Both K&R and BSD style uses hard tabs, as does Linux kernel style and most older GNU project code for that matter. Various Unix programs assume tabs, for example indentation elision in shell heredoc syntax ("<<-") only works for tabs.
Soft tabs (spaces) has been a relatively new thing in the C/Unix world. You may not notice it because, working as well as they do, hard tabs magically indent according to your local preference, so hard tabs aren't noticeable.[1]
[1] What doesn't work is right-hand alignment. That's most noticeable in modern BSD code, where the style is to tab-align variable types and names into different columns. If your tab stop isn't set to 8 (the required tab stop), they don't line up. Most hard tabbers don't mix indentation and alignment, anymore.
EDIT: Here's the earliest source code for vi I could quickly find: https://github.com/n-t-roff/ex-2.2/blob/220a2cfa/ex.c
It uses hard tabs. It's also still using pre-ANSI function syntax, suggesting this code wasn't cleaned up before committing to Git.
Ok apparently I'm super ignorant about this. WTF are people going on about spaces for if hard tabs are the historic standard? I always assumed that Go was progressive, C++ was the norm (ie had no preference), Python and Nim were designed by diehards clinging to the past, and that people were exhibiting their rather famous resistance to change. Apparently this is completely wrong?
I seem to have made assumptions due to only running into spaces in "old" places such as Python, Vim, Emacs, etc. To be fair, this all happened well before I was born. Why would software developers of all people try to do away with a useful abstraction?!
Oddly, the linked keyboard doesn't appear to have a tab key but the Vi source code you found contains them? Am I missing something obvious?
(`/* Copyright (c) 1979 Regents of the University of California */`, that's some impressively old code to find on GitHub.)
Re BSD: Yeah, tabs don't work for alignment almost by definition. I'm surprised anyone was crazy enough to author a code style that called for it.
Bit strange thinking of Python as "old" .. anyway, what I suspect happened was that tabs were the "new" innovation - in the post-punchcard era. Punchcards couldn't meaningfully have a tab character, but they could have fixed character positions, and this feature was required by COBOL and FORTRAN in their day. It was still present in the F77 standard.
I think the other thing that got in the way of standardising on TAB was that 8 character indent is too much, but once you let people configure it it's no longer consistent between systems.
> that's some impressively old code to find on GitHub
Python is about 30 years old. Started by Guido van Rossum in December 1989.
Python is older than HTTP, older than the Web.
It's older than most programming languages still in common use today (TIOBE).
I think most people would think of Python as "old" if they thought about its history. Its current cool factor in AI and employment makes it seem newer than it is.
> Oddly, the linked keyboard doesn't appear to have a tab key but the Vi source code you found contains them? Am I missing something obvious?
Vi has the insert-mode commands for indenting (Ctrl-T) and unindenting (Ctrl-D) the current line. If you're used to them, you don't really need Tab except for aligning things within the line. Also, Tab is Ctrl-I.
I believe VT52 and VT100 terminals have a physical ESC key where you would expect it to be. On newer models, like VT220, etc, you can use the setup screen to put them in VT100 mode. Once you do that, the F11 key will function as an escape key.
Also note it was viewed as a weird choice to omit the key at the time. Televideo, a competitor, called it out in their ads: https://imgur.com/a/u7KHRjQ
Somewhat interesting that Apple recently took away, then gave back the ESC key on their pro laptops.
I still want my Meta key! How can we do Ctrl-Alt-Meta-Cokebottle? But, seriously, having three "control-like" keys gives us 8 'name-spaces' using different combinations of Ctrl / Alt / Meta. Pretty convenient.
This is a feature of some game engines which allow people to use arbitrary keys (or combinations) as modifier keys. Which allow for less motion of the hand over the keyboard, by simply being able to hit the same keys (with some modifiers) quickly.
You would need an N-key-rollover keyboard to be able to do this, at least in the general case. Baseline keyboards do not register overlapping keypresses correctly, unless you are using the ordinary modifier keys.
Sure, but a lot of gaming hardware supports this, and it's a hardware issue. If one is customizing their editor to the point of using arbitrary modifier keys, they will probably be willing to buy a custom keyboard.
Also while on the subject 8 key rollover, which is pretty common, is probably more than enough.
I never knew about this. My laptop seems to have 8-key rollover for most (?) sequences that would be natural for your hands, but drops as low as 2-key for unlikely combinations. Any idea what's going on?
In my many years of Unixing, I never used any vtxy0 with x greater than 2. The vast majority were vt100 or close. Especially compatibles; the few genuine DEC terminals that came with the machine were left in the machine room.
The article is simply incorrect. The VT100 (and VT52 before it) had an ESC key, right where you'd expect it to be. Just about any terminal you might have bought in the 1970's had one.
Back then I wouldn't use a DEC terminal newer than a VT-100 because of the lack of an ESC key. The 220s were physically great terminals, but the keyboard layout was horrific for using vi.
Around 84 we started evaluating a purchase of hundreds of terminals for the university, and eventually settled on the Wyse WY-75, mostly because it was ANSI/VT-100 compatible and had an escape key.
DEC didn't care, because they didn't use the ESC key in VMS.
> Ctrl-3 and Ctrl-[ could send the character. However, this is downright terrible for both vi and Emacs (as this is the only way to trigger meta commands in Emacs).
Anecdotal, but I use Ctrl-[ in vi all the time. More comfortable the escape key in my experience. I've tried jj and jk, but I inevitably end up on a system without my .exrc or init.vim at some point, and struggle. Ctrl-[ has the benefit of working everywhere.
All of the RS232 (serial i/o) VDUs had hardware handshaking. A common problem was that some serial cables lacked ALL the wires required. i.e. the bare minimum serial cable has only 3 wires (ground, in, out). Cables with more wires have greater capabilities (handshaking, modem control,etc,etc).
I have a vt420, vt510, and IBM3151 and not one of them do RTS/CTS like we'd expect. The vt510 can apparently do that on the DTR/DSR pins, but the vt420 and below cannot, and neither can the 3151.
I don't think that hardware handshaking was universal, but it's ancient enough history that I can't state it categorically. I do know that RS-232 wasn't designed symmetrically so there was some confusion on which lines would do what.
Perhaps not "universal", but every RS232 interface I ever came across, starting in 1979, supported hardware flow-control, though you could also do it in software.
One of the nice things about RS232 is that it was specified that you could scrunch up the individual wires of the cable and it wouldn't damage the interface circuitry (good for crappy solderers like me) and you could hot plug and unplug it. Oh, all right, TWO of the nice things :-)
> why would both of these editors be developed in such a way that they are downright inconvenient to use on the hardware on which they most frequently ran?
As other comments note, they were developed on earlier models or non-Dec terminals.
Also Emacs was not developed on Unix. The first Unix Emacs was created by James Gosling of Java fame.
Certainly not. The first emacs was created for the TECO editor on ITS by various people. It was further developed and maintained by RMS. Gosling's emacs came a few years later.
https://github.com/larsbrinkhoff/emacs-history has the details... there's some Gosling code (notably display.c with the skull-and-bones warning) in Emacs 13, but none that I can find in 15 and later.
Not a history book, per se, but a great tour into the culture and philosophy of Unix: The Art of Unix Programming [1], by Eric Raymond. Chapter 2 is titled "History."
You also have resources like The Unix Heritage Society [2], who show a timeline of historic events on their wiki [3].
I bought Brian Kernighan's memoir [4], which so far is an incredibly detailed and personal account of his time at BTL.
Thanks for this blast from the past. I bought the book in 1997 as a sophomore student at university. My favorite book at the time. Leafing through the PDF after all these years I came across some gems I hadn't appreciated back then:
On page 161 the author mentions in passing that Eric Schmidt had been working on BerkNet. THE Eric Schmidt. The Google Eric Schmidt.
Earlier the book mentions that Bill Joy was able to hire a developer with money they got from DARPA. That developer was Michael Toy and later Sam Leffler. There's a movie called Code Rush about the open-sourcing of Netscape's source code in 1998 (which begat Mozilla and Firefox) and Michael Toy was the project lead for the open source effort back then. Sam Leffler later developed TIFF.
Brian Kernighan 'interviews' Ken Thompson (2019) - Ken telling stories. They're both very funny, a very entertaining video, some stories I (and even Brian) hadn't heard.
Also the other day I read in the AWK book that it was mainly inspired by SNOBOL4, so looked at some SNOBOL4 books from archive.org, from 1970-2 and just before, slightly earlier than Unix history takes you back. One tells you how to organize your punch cards to feed in the program.. Another had a bibliography with many dozens of SNOBOL books. It was widely used by people in the humanities apparently; like AWK it was at home dealing with words and text.
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