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

[Vincent Lefevre]

On 2006-06-18 22:25:02 +1000, Vincent Ho wrote:
> 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.

They are meant to be used by applications (possibly via a library),
in particular when XLookupString is empty (e.g. for function keys).

> Backspace and Ctrl+H may often have the same visible effect, but
> they are completely different XKeySym values.

Yes, that's why the keysym is useful. For instance, Emacs does the
difference between Backspace and Ctrl+H.

> Each KeySym only corresponds to a key, not to a character value.

The application (e.g. xterm) can do the necessary translation, which
is often more or less configurable.

> 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.

But depending on how the terminal is configured, the Backspace key gives
0x7f (DEL character) instead of 0x08. This shows that the terminal takes
the keysym into account (at least in this case).

> 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.

Yes, for some keysyms, the terminal will use XLookupString.

> > 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.

But it also uses the keysym, as I've shown above. Anyway, the terminal
should use the keysym *or* XLookupString.

> > 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.

Perhaps, but other GTK applications (e.g. Mozilla) used to take the
key into account (probably with XLookupString), but IIRC, instead of
regarding it as a Ctrl-A command, they inserted the 0x01 character.
In a terminal, there shouldn't be any difference, though.

-- 
Vincent Lefèvre <vincent at vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA