Bug#306554: gnome-terminal doesn't honor xmodmap settings

[Vincent Ho]

Hi Vincent!

On Sat, Jun 17, 2006 at 12:59:58PM +0200, Vincent Lefevre wrote:

> I don't think xterm does it either, otherwise it wouldn't be able
> to make the difference between Backspace and Ctrl-H, for instance.

As I understand it, XKeySyms are just abstract hardware-independent
names/values for keys, not meant to be used as character input by
applications.  Backspace and Ctrl+H may often have the same visible
effect, but they are completely different XKeySym values.  Each KeySym
only corresponds to a key, not to a character value.  If I run xev and
press Backspace, I get:

  keysym 0xff08 (BackSpace), XLookupString() 1 byte, 0x08

The BackSpace keysym has value 0xff08, which is definitely not being
inserted into apps.  But XLookupString() returns 0x08 (^H), which might
be.  If I press h by itself, I get:

  keysym 0x68 (h), XLookupString() 1 byte, 0x68 "h" (ASCII 'h')

If I press Ctrl+H, then for the h keypress I get:

  keysym 0x68 (h), XLookupString() 1 byte, 0x08

Note how that's still the same 'h' keysym value, but obviously we don't
insert 0x68 (ASCII 'h')  when you press Ctrl+H.  In contrast, we have a
different XLookupString() result due to the Control modifier being
pressed.

> I'm not asking to use XLookupString(). The keysym should be used.

Well I think I've shown above that keysym values aren't meant to be
inserted character values.  I've checked the source of xterm and it
calls XLookupString() in its Input() function.

> Finally, the problem may be the fact that keysym 0x1 is not supported
> by vte/GDK.

I've rebuilt libvte with debugging enabled to see what it prints out.
Running gnome-terminal against this libvte4 with
VTE_DEBUG_FLAGS=keyboard, I get:

Mapping 0x0001 Shift+(unknown) (ignoring, no map for key).

so I can confirm that vte is discarding it. If you run xmodmap -e
"keycode 100 = Left Ccedilla", then pressing Shift+Left gives you a "Ç"
character as you'd hope.  For "a" and most printable keyvals, vte
successfully calls gtk_im_context_filter_keypress(), but not for a
keyval of 0x0001.  I think as we suspected, GTK simply doesn't support
that.  I'm not sure that this should be a bug, and even if it is, it
would get reassigned to GTK.


   Vince

-- 
  Vincent Ho

"If we hit that bullseye, the rest of the dominos will fall like a house
of cards. Checkmate."