edrbtsn@iuvax.cs.indiana.edu (Ed Robertson) (07/06/89)
I am looking for information on how GNU uses X windows' keysym bindings. For example, the keysym Left (nornally corresponding to the physical key for left arrow) transmits the character "C-b" (which is the correct thing for left-arrow with the default emacs keybindings but not for my purposes). In any case, GNU obviously knows that it's dealing with X or with a VT-100 (emulator), since it overrides defaults set by xrdb. Knowing that everything else in GNU has features for generalizing specific operations, I assume that GNU has some special hooks for dealing with X but I can't find any information. I'ld appreciate pointers. Thanks. -- Edward Robertson robertson@cs.indiana.edu Computer Science Dept Indiana University 812-855-4954 Bloomington, IN 47405-4101
boberg@june.cs.washington.edu (Bruce Oberg) (07/07/89)
In article <22974@iuvax.cs.indiana.edu> edrbtsn@iuvax.cs.indiana.edu (Ed Robertson) writes: >I am looking for information on how GNU uses X windows' keysym bindings. > >For example, the keysym Left (nornally corresponding to the physical >key for left arrow) transmits the character "C-b" (which is the correct >thing for left-arrow with the default emacs keybindings but not for my >purposes). ed has stumbled into a small, infuriating "feature" of the gnu emacs 18.52 (and possibly earlier). in the file x11term.c, there is a section which handles incoming X11 KeyPress events. there is a small, tidy case statement which *HARD CODES* incoming cursor keys into C-n, C-p, C-b, and C-f. short of rebuilding from the sources, there is no way to change these mappings! a couple other problems within a few lines of that one are also fairly frustrating to DEC workstation users. the IsFunctionKey() and IsMiscFunctionKey() macros are used to trap incoming function keys and translate them into the appropriate (DEC or SUN) escape sequences. unfortunately, the "prev screen" and "next screen" keys (keysyms XK_Prior and XK_Next) are not caught by the above macros, rendering them unusable within emacs (they could be caught by IsCursorKey()). finally, the keysym for the DEC "remove" key (DXK_Remove, defined in /usr/include/X11/DECkeysym.h) is the bastard child of X11, being completely ignored by xmodmap, emacs and *all* the keysym macros. this appears to be a global X11 problem - one without a clean solution since the keysym space is pretty cramped around the function key definitions. xterm handles the above problems with a special clause for handling incoming KeyPress events, properly translating both XK_Prior, XK_Next, *and* DXK_Remove! i get around the emacs problem by xmodmap'ing the Prior, Next, and Remove keys to spare function keys that i never use. then i set up a keymap via the emacs keypad.el macros to trap on the function key sequences and Do The Right Thing. one nice thing you can do if you have lots o' function keys to spare is map *shifted* keys to more function keys (e.g. xmodmap -e 'keysym Up = Up F17'). then you can trap on the function key sequences and do what ever you want. for example, i have my shifted left and right arrow keys mapped to 'forward-word' and 'backward-word' respectively. the real solution to the above problems is a minor rewrite to the code in x11term.c. i'd do it myself if i knew 1) where to send it and 2) that it had half a chance of getting into a fix release. where should i send GNU emacs bug reports? bruce oberg "...a just machine to make big decisions, programmed by fellows with compassions and vision. we'll be clean when their work is done, we'll be eternally free... yes, and eternally young..."