keycodes all off by one with GTK and $DISPLAY pointing to an R5 server

[Glynn Clements]

Kean Johnston wrote:

> > As I indicated in my other mail, it's probably some bug in GTK+
> > or incompatibility with your keyboard map, but really impossible
> > to guess without seeing that keyboard map.
> 
> Thank you Owen, that was a big help. For the sake of completeness,
> I am attacking the results of xmodmap -pk from the R5 and the R6
> servers. As you can see, the R6 server is all off-by-one with
> regard to the R5 server.
> 
> What's confusing me is this. Obviously, the event that gets
> generated by teh R6 server works. Its generating keycode 9
> for ESCAPE, and the R5 one works too, its generating 8 for the
> ESCAPE. The keysym in both cases is correct. What's really
> view weird is that with gvim (using gtk2), only the 'q' and
> 'Tab' keys seem to be affected. w works just fine, as does
> Backspace, which is the keycode before it. Most bizarely,
> it treats 'q' and 'tab' as the *same*, not offset by 1.

Could this be a bug in the ISO_Left_Tab hack?

	  for (i = 0 ; i < 2 ; i++)
	    {
	      if (get_symbol (syms, keymap_x11, i, 0) == GDK_Tab)
		syms[KEYSYM_INDEX (keymap_x11, i, 1)] = GDK_ISO_Left_Tab;
	    }

If there's a bug in KEYSYM_INDEX, I can imagine it overwriting the 'q'
slot rather than the Shift+Tab slot.

-- 
Glynn Clements <glynn at gclements.plus.com>