bug#7380: 23.2; Dead keys misinterpreted in gtk emacs

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> Under X11 with the us_intl keyboard, dead keys are not correctly
> combined with the following characters.  For instance <dead-acute> e,
> which ought to give é, instead produces the message "<dead-acute> is
> undefined" followed by an undecorated e.  The problem is specific to
> emacs: all other applications in the same X11 session (Firefox, xterm,
> urxvt, miscellaneous gtk apps like exfalso) accept accented input
> typed with dead keys without special customization.  This is a
> plain-vanilla install of emacs under pkgsrc.  The auto-collected data
> reported below were generated by M-x report-emacs-bug from an emacs -Q
> instance displaying this behaviour.

It vaguely reminds me of some other bug-report.  But that's about as far
as it goes.  I don't use dead keys, but I do use the <Multi_key> daily to
enter most of my non-ASCII letters, which should rely on the same code.

> the price of the graphical comforts of gtk emacs.  I can also activate
> iso-transl and have emacs handle the composition of characters from
> dead keys by its own internal mechanism, independent of X11, but then
> I get a subtly different keyboard layout in emacs relative to other
> software on the system.

iso-transl is at best a workaround.

I just played with xmodmap to add a dead-acute key to my keyboard, and
"it works here" with all versions of Emacs I threw at it.

Now, as to why this X11 key composition does not work for you.
Could you maybe try to rebuild it and show us the output of "configure"?
Not sure it'll help, tho.  We'll need either someone to be able to
reproduce it, or you'll need to dig in the code, play with GDB to try
and see what's going on there.  If you're up to it, you can try and
place breakpoints near the call to XmbLookupString in xterm.c and single
step there.  Normally, the dead-acute event should not escape from this
part of the code: instead it should turn into "nothing" (just change
some state somewhere either in compose_status or in "FRAME_XIC (f)"
depending on whether that frame uses XIM/XIC), and subsequent "e" should
in that same part of the code be turned into an "é" (so the Elisp code
never even gets to know that this é was input as two separate key
presses).


        Stefan