Emacs on Athena Terminals: The Right Keys to Press One of Project Athena's stated goals is something called "coherence." The exact meaning of this word has proved elusive, but in one particular context there is agreement: as regards terminals it means that the person who walks up to an Athena terminal and tries to use it should have a reasonable expectation that the buttons he pressed to get a particular effect on one terminal should work to get the same effect on another terminal, even though it is a different model or from a different manufacturer; that the number of arbitrary, hidden little "gotcha!-betcha-can't-guess-whys" should be kept to a minimum. Well, we're not there yet. The Emacs text editor brings out the worst in the differences among terminals because, by relying upon control and escape keys to make its commands, it skates closest to the area where industry standards peter out, hardware designers find room to play, and terminal emulator writers start saying, "Oh, the heck with it, who's going to want to type control-spacebar anyway?" Athena has had two main problems with Emacs and our different terminal makes. The first problem is flow control, sometimes known as "the control-S problem." This is the most serious problem. It has had effects that extend far beyond just Emacs. It will be discussed in a future article. The second set of problems has come with the Emacs "control-punctuation mark" commands. These are the Emacs commands issued by holding down the control key (CTRL) and then pressing a special character such as @, ?, or _ (underscore). One can be reasonably sure that typing a CTRL-A (jump to the beginning of the line) to Emacs on one terminal will produce the same bits that a CTRL-A produces on another terminal. However, terminals get very inconsistent about what bits they will produce when a CTRL-punctuation mark keystroke sequence is pressed. Sometimes the key is "dead" and produces nothing. Sometimes it works fine. Sometimes you need to press a completely different, unrelated key to get the right bits. And sometimes several keys will produce the same code. Emacs uses a number of these CTRL-punctuation mark commands. These CTRL-punctuation mark Emacs commands are not all obscure non-entities that you will never have to worry about. A few are very important. For example, the Emacs Set Mark command, necessary to copy and move regions of text, is documented to be CTRL-@. CTRL-@ is "dead" on VT100 and VT125 terminals where you must use CTRL-SPACEBAR instead; VT240 and Pro350 terminals are easygoing and will take either; while CTRL-@ works on an IBM PC but CTRL-SPACEBAR does something completely different. Gotcha. Figure 1 shows, for each Athena terminal, which CTRL-punctuation mark sequences you have to hit to make the commands work. The Figure also shows what happens to all of the CTRL-S commands on different Athena terminals. The variations in CTRL-S commands from graphics to non-graphics terminals are caused by the flow control problem noted above. Flow Control The problems with Emacs CTRL-punctuation mark commands are merely irritating. Athena'sproblems with Emacs and flow control have been serious. It is not really necessary to understand what is going on in order to follow these precautionary steps: - If you want to do graphics, always use a graphics terminal that is hardwired to the home machine you are going to use. You can tell which machine a terminal is "really" connected to by looking at its login server banner: Athena Login Server (mit-hera on tty01) This terminal is connected to hera. You should use a hera terminal to do graphics on hera. Since dial-up users cannot do anything but connect through to a different machine, dial-up graphics may not work reliably. - Avoid using VT125 graphics terminals for Emacs editing work. If you do, follow Figure 1's instructions for that terminal. If you accidentally hit a CTRL-S while in Emacs on a VT125 terminal, and the terminal appears to go dead, you can usually start things up again with CTRL-Q. Remember, if you get absolutely stuck, the instructions for killing a login session from another terminal are described at the end of both Essential Unix and the Dial-Up Access writeup. Athena is working on Emacs to correct the problems that caused us to turn off flow control between machines. When these are fixed, we will be able to turn flow control back on again. We hope to install this fix in January, 1985. The different elements in the chain of interaction between users and programs work at different speeds. Users, when reading screens, work in the vicinity of 500 baud (well, this user, anyway). Hardwired terminals work at about 9600 baud, although graphics terminals plotting data and micros running terminal emulators can be considerably slower. Programs produce data at all speeds, depending upon themselves and how loaded the system is. There can be more players in the game. Most Athena users login to their home machines through other machines via the login server. All their interplay with the system is relayed through another computer. There can be additional communications equipment such as modems and multiplexors in the chain. Terminals, again, particularly graphics terminals, are small computers with buffers to collect the data as it comes from the main system and relay it to their screens. How do the slower participants in this system prevent the faster elements from overrunning them with data? Most equipment uses the conventional X-ON, X-OFF flow control mechanism. When one element feels it needs a pause, it sends an X-OFF (hold it a minute, stop sending me stuff) to its neighbor. That neighbor has a decisions, do I stop sending but keep receiving, and do I forward the X-OFF up the line? Usually, the X-OFF is forwarded. Like cars stopping on a busy freeway, the "hold it!" ripples down the chain until the program actually producing the data is halted. When the slow element decides it wants to start up again, it sends an X-ON to its neighbor, who forwards it, until the program starts again and data again flows. The standard X-OFF character is CTRL-S. X-ON is CTRL-Q. When you hit the NO SCROLL key on a VT100 or CTRL-S on any other terminal, this is what you are doing. Into the midst of this well-ordered, industry-wide standard, steps Emacs, who has decided that it is going to use CTRL-S to mean "search for string". The question arises, when a user presses a CTRL-S, is he asking to stop data flow? Or is he in Emacs and asking to search for a string? Right now, we can't always tell. This has caused enormous problems. There have been two main problem areas: Emacs through the login server and Emacs on VT125 and VT241 graphics terminals. Emacs Meets the Login Server When you run Emacs on the same host machine that your terminal is physically hardwired to, there are no flow control problems. When you start up Emacs, Emacs disables CTRL-S as a flow control character on the local machine, ensuring that any CTRL-S a user types will not be intercepted, but will be passed through for string searches. What flow control needs to be done, Emacs handles itself based upon what it knows about your terminal's speed. When you leave Emacs, CTRL-S flow control is turned back on. In this simple case, Emacs isolates itself and controls its own problem. Enter the login server in September, 1984, that made it possible for users to login to any machine in a cluster from any terminal in that cluster. (The 1200 baud dial-up number works the same way.) Now, the host computer your terminal is connected to passes all of your interactions through to your real home machine. The data flow between the two systems is regulated by CTRL-S, CTRL-Q. But now, when you start up Emacs on the remote machine, it sends its message "ignore CTRL-S's, send them all to me" only to the system it is running on--your home machine. The host machine you are connected through never gets the word (ignore all CTRL-S's). So, when you try to search for a string in Emacs by typing CTRL-S, what you really do is turn off the flow of data between the two computers. Maybe the CTRL-S gets through to Emacs, maybe not. What does happen is that your terminal suddenly seems to have gone dead. A CTRL-Q will start things up again. To accommodate Emacs's CTRL-S problem through the login server, Athena elected to turn off all flow control between host machines. There is no danger of an Emacs CTRL-S being intercepted because CTRL-S are being ignored between the hosts, anyway. This had other bad side-effects. Now, CTRL-S no longer works for its real purpose and users cannot stop and restart data being displayed on their screens. (Although the terminal and local machine stop showing it and it appears to be working, the remote machine doesn't and you are really loseing large chunks of data from the middle of the file.) Graphics terminals, who run slowest and rely most heavily on flow control, have stopped working over the login server, too. If you want to do graphics, you must select a terminal that is hardwired to your home machine. People who had been doing file transfers between their micros and Athena hosts over dial-up lines can no longer do so reliably; data can easily be lost. Clearly, this isn't going to work in the long run, either. Athena is currently fixing Emacs to work the same isolation trick over the network that it performs on a single host machine. When we get this working--tentatively planned for January, 1985--we will turn flow control back on between hosts and the bad side-effects should go away. There are tricky timing problems that make this more complicated than it would seen at first. Emacs vs the VT125 and VT240 Athena's two primary graphics terminals have a hardware design quirk that causes them to have a great deal of trouble with Emacs. Whereas most terminals will take a user-entered CTRL-S, and forward it up the line to the system, VT125 and VT240 terminals in graphics mode take the CTRL-S and stop sending data from their internal buffers to the screen before they pass the CTRL-S along up the line. The effect is the same as any prematurely-intercepted CTRL-S string search command on its way to Emacs: the terminal appears to have gone dead. You can usually start things up again with CTRL-Q, but unless you realize what's going on, you probably won't think to do this. Moreover, the VT125 terminals can get into a state where they become absolutely jammed and the only way to free them is to turn the terminal off and kill the terminal session from a different terminal. Most of the original Athena terminals were VT125s. To avoid an endless succession of jammed terminals that were already confusing Athena staff, and to avoid invalidating all of the Emacs documentation, Athena elected to remove the graphics boards from most of its VT125s and turn them back into garden-variety, no-graphics VT100s. $50,000-worth of graphics boards went back into their boxes and only a few real VT125s were left. In fact, Emacs is clever enough to realize when it is being run on a VT125. It's solution is to give up on CTRL-S as the string search character and redefine string search to be CTRL-T. Emacs can avoid getting confused, but it was unlikely that most users would realize or appreciate that the switch had been made. The newer VT241 graphics terminals have the same problem. The difference is that the only way to get a VT125 to leave the CTRL-S alone is to lobotomize it back into a VT100. VT241's can be convinced to behave properly by changing their X-ON/ X-OFF set-up option to OFF. In this mode, the terminal loses its ability as a graphics device, but works transparently with Emacs. It can be converted back into a graphics terminal by just turning flow control back on in the set-up menu. There is, no permanent, idealized, transparent fix to this problem. The demand for graphics devices by courses has been stronger than we originally envisioned, so it appears that we will have to accept the potential for confusion and set-up more graphics terminals.