Arrow Keys, NumLock and Keypad jimc, 950616 In the X Window System the xterm terminal emulator closely emulates a DEC VT100 terminal, which has a numeric keypad, that is, a set of digit keys to the right of the alphabetic section. These are very useful for entering large amounts of numeric data; I have found it well worth the effort to learn how to touch-type on them. One variant of the VT100 had alternate labels on the keypad such as insert, delete, and arrow keys. A number of DEC applications would shift the keypad into "application keypad mode" in which it would generate special codes, not digits, that would signal useful actions. At the same time the ANSI X3.64 standard for terminal control sequences was just being written, and the ANSI arrow codes were different from the VT100 application arrows. Imitating the DEC applications, Bill Joy when writing vi went to a great deal of trouble to go into application keypad mode, so that people could use the specially labelled keys on the VT100. When xterm was written it imitated the VT100 in recognizing the keypad, if the X-terminal or workstation had one, and generating application keypad codes (not digits) when told to do so by vi. Since nobody remembers the old DEC key labels, and very few know how to bind them to vi editing actions, the keypad was rendered useless. Emacs of course does the "right" thing and imitates vi's behavior. In a fit of iconoclasm we at UCLA-Mathnet have now disabled the shift to application keypad and arrow mode. Thus on many keyboards the keypad will now generate digits all the time. On the Sun type 4 or 5 keyboard (and possibly others) with NumLock pressed the keypad will generate digits, or without NumLock the pad arrows will be correctly interpreted as arrow keys. The arrow key control sequences will be recognized as arrows both by the editors and by non-editor applications such as Gopher. (The X11R6 server is needed on Suns; the X11R5 server only generates arrows, not keypad digit codes.) There is a question of compatibility with non-Mathnet sites. If a Mathnet user connects to a site using the traditional key arrangement, the keypad will be useless in that connection only. If a non-Mathnet user connects to a Mathnet machine his keypad will be operational, as if he were a local user. If a rlogin connection from Mathnet to a foreign site is broken unexpectedly, the keypad could be left in application mode; the command "reset" will put the pad and arrows back to their normal mode. For the masochistically inclined, here is a discussion of which parts of the X Window System are to blame for various parts of the keypad problem. The Athena X11R6 server for SunOS-4 has a default keymap which is correct in that it gives correct keysyms (e.g. Home, Prior) for the correspondingly labelled non-keypad keys (e.g. Home, PgUp). For the keypad keys, using the key labelled 8/Up as an example, it generates {KP_Up KP_8}, which is reasonable. (The X11R5 Athena server omitted most nonalphanumeric keysyms.) The Num_Lock key is mapped to the appropriate keysym with Mod4. Without Num_Lock, Xlib normally translates the keycode into the first keysym (KP_Up in this case), but with shift it uses the second one, KP_8. KP_8 has a builtin (?) ASCII interpretation as '8'. Thus any app that uses XLookupString will see as ASCII '8'. xterm in both X11R6 and X11R5 do this. Empress does not. When processing a keycode, Xlib looks to see if the modifier on Num_Lock is engaged. If so, and only if the second keysym in the keymap for that keycode is KP_anything, Xlib inverts the shift modifier so that unshifted would mean KP_8 and shifted would mean KP_Up. This works in X11R6 xterm in command line mode but not on X11R5 xterm, but this may have been because the server was not generating the keysyms. xterm interprets both KP_Up and regular Up as arrow keysyms. It can send one of two codes to the child process: application and ANSI cursor codes. In ANSI mode Up is \E[A, while it is \EOA in application mode. There are also two modes of operation of the keypad: application and regular. The regular codes are the digits or arrows, depending on Shift and Num_Lock; the application codes are random \EO? where ? is some letter. You can switch into and out of these modes by application-generated escape sequences (\E= for pad and \E[?1h for cursor) or by the middle menu. The initial setting is determined by the app-defaults file (regular/ANSI). When you log in, loginexp sources askterm which, among other things, uses tset to transmit the is= termcap, which among other things initializes the pad and arrow modes. When vi or emacs starts up it sends the ks= termcap string. In the termcap distributed with xterm, which we have been using, ks= puts the pad into application mode and engages application arrows. On exit ke= is sent which returns to regular/ANSI mode. Thus during command line operation you get ANSI arrows and numlock works, while in the editor you get application arrows if you press the separate arrow keys on a type 5 keyboard, but the keypad generates garbage whether or not Num_Lock is pressed. The ku= termcap (and friends) tell the editor to look for application arrows, so these do work. On the other hand, unsophisticated command line applications that use curses will get ANSI arrows, and thus will not recognize arrow keys. Empress is unique: it apparently doesn't use XLookupString, so it doesn't know about the numeric keypad, and it is looking for Left and Right keysyms, not KP_Left or KP_Right, so only the separate arrows will do (if one has separate arrows, which a Sun type 4 keyboard doesn't). These changes were made: termcap and terminfo were modified so the initialization and reset strings put the xterm into ANSI arrow mode and regular keypad mode. The ks= and ke= strings were removed so that the xterm stays in that mode all the time. The arrow recognition strings ku=, kd=, kl= and kr= were changed to the ANSI codes. Then pad arrows and Num_Lock will both work all the time (not at the same time, of course). NCD and Xkit keyboards ignore numlock and generate digit codes all the time from the keypad, unless in application mode.