Description of Problem: termcap seems to have no entry for the emacs terminal type. e.g.: start xemacs Tools -> Shell... unknown terminal "emacs" unknown terminal "emacs" also: When xemacs starts up I get this warning: (1) (key-mapping/warning) XEmacs: Mode_switch (0x71) generates both Mod1 and Mod3, which is nonsensical. I mentioned these to an xemacs team member and he suggested they were a distribution issue.
XEmacs shouldn't set terminaltype to "emacs", it should use "dumb". As for the mode_switch issue, that would be related to X... what does your keyboard section in X look like?
Section "InputDevice" Identifier "Keyboard1" Driver "keyboard" Option "AutoRepeat" "500 20" Option "XkbRules" "xfree86" Option "XkbModel" "pc105" Option "XkbLayout" "gb" EndSection I'm running KDE from Rawhide also, if that is relevant. I can't find any way to set the term type within xemacs.
The modifiers is an X issue (try setting "102" keys there to get rid of this message) - I've not yet found where xemacs sets terminal to "emacs" (or any reason for doing it... - it's broken behaviour. Try GNU Emacs instead :)
Using Xkeycaps I can fix the modifier key problem - Alt Gr is configured to MOD_1 and MOD_2 - resetting to default 105 key UK keyboard makes it work OK. I'll talk to the xemacs people about the terminal type settings.
Reassigning the keymap issue to XFree.
This happens for a Swedish keyboard with XFree86-4.1.0-0.9.4 too. With my XF86Config-4 including Option "XkbLayout" "se" Option "XkbModel" "pc104" I get a modifier setting looking like this: xmodmap: up to 2 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Mode_switch (0x71) mod2 Num_Lock (0x4d) mod3 Mode_switch (0x71) mod4 Super_L (0x73) mod5 Scroll_Lock (0x4e) Mode_switch should only belong to mod3. I think, but am not positive, this has happened sometime after 4.0.1-1. (I didn't have any problems before I upgraded. But I can't easily go back to verify at the moment.)
I've done some investigation on this (w/o any documentation whatsoever of the file format used in /usr/X11R6/lib/X11/xkb/) and it seems like the following happens: <RALT> is defined to Alt_R, Meta_R (symbols/us:178) Mod1 is defined to Alt_L, Alt_R, Meta_L, Meta_R (symbols/us:181)<RALT> is redefined to Mode_switch (symbols/en_US:35) Mod2 is defined to Mode_switch (symbols/en_US:42) the relationship between us and en_US seems to be defined by the statment 'augment "us(pc105)"' that I don't know the meaning of, but it seems impossible to redefine the modifier_map for Mod1 once it is defined. So the solution as I see it, without serious XKB code hacking is to remove the modifier_map from symbols/us:181. The only side effect this would have is that when using the pc105 Shift-AltGR wouldn't behave the same as AltGR. The real fix of course is to really understand what is happening and remove Mode_switch from Mod1 when it is used in Mod3
I've investigated this a bit, and am unable to find a solution which works properly. I'm no expert in this particular area any more than any of you are, so it is something that should be reported upstream to XFree86.org, and fixed in the upstream release by someone more familiar with manipulating these files. They'll likely be able to fix it more promptly and correctly, and we can then pick up the fix from the next XFree86 release. Please report to xfree86 and xpert.
Has anybody else reported to XFree86 yet? If nobody says anything; I'll send a report shortly.
When checking, this doesn't seem to happen any more with XFree86 4.2. I guess it was fixed upstreams, so I won't report anything.
Reopened... Resolving as RAWHIDE
You could probably even had done CURRENTRELEASE. 7.3 had XFree86 4.2. (I haven't verified it on a pure 7.3 system, though.)