From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020724 Description of problem: Some applications seem to display the diaeresis character as the double quote, but gnome-terminal and other gnome applications get them different, which makes it awkward to enter shell code containing double quotes, because there's no easy key sequence to type it in. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.setxkbmap us_intl 2.start say GNU emacs or xterm 3.type double-quote space, double-quote twice, then Right-Alt Shift double-quote 4.start gnome-terminal, gnome-text-editor, and many other gnome applications 5.type double-quote twice, then double-quote space, then Right-Alt Shift double-quote Actual Results: For 3, you get diaeresis, quotedbl, quotedbl (even though diaeresis doesn't display as such on GNU Emacs; that's a separate bug already) For 5, you get diaeresis, diaeresis, quotedbl. Expected Results: I expected to get 3's results on 5 too, as defined in XFree86 UTF8 Compose rules. Additional info: All of these commands are run with LANG=en_US.UTF8.
FWIW, konsole and other KDE applications I've tested exhibit the correct behavior. Also, contrary to my initial description of the problem, it's not about displaying characters incorrectly, it's about getting the meaning of keystrokes incorrectly.
In en_US/.UTF-8Compose, I see: <dead_diaeresis> <space> : "\"" quotedbl <dead_diaeresis> <dead_diaeresis> : "(" diaeresis Which looks backwards from what you have above for the xterm/emacs case... The GTK+ universal compose table got these mappings from the iso-8859-1 Compose sequences ... so it does the same thing as the keys would have done in previous releases. The Xlib en_US.UTF-8 table disagrees with the iso-8859-1 table. BTW - You can make GTK+ use the Xlib compose tables if you set GTK_IM_MODULE=xim (gnome-terminal doesn't currently offer a way to select that interactively, most apps have a right click menu.)
Oops. Sorry. Steps to Reproduce.3 should have read like 5. The iso-8859-1 compose tables were wrong (IMO) in earlier releases, an opinion shared by a number of other users of international keyboards I know. I still haven't checked whether they've been corrected, but a patch for XFree86 to fix them was sent a while ago.
FWIW, iso8859-15 had got the diaeresis compose rules right, but iso8859-1 still had them wrong. I've just submitted a patch for XFree86 (internal and upstream) that fixes this and a few other oddities in the iso8859-1 compose tables. Bug 71014.
Where is it that the gtk2 encoding tables are stored in the gtk2 source tree? I can try to fix them myself, and some pointers would surely help me get to it :-) Thanks,
gtk+/gtk/gtkimcontextsimple.c Ignore the comment about the Perl scripts ... if I have them any more, I don't know where they are. (And there was quite a bit of hand editing involved as well in getting to the current form.)
The following patch adjusts the behavior of quotedbl space and introduces double-dead-accent sequences for the grave and circumflex accents, that would formerly generate nothing. It also rearranges the similar sequences for acute accent and tilde, so that they're all in the beginning. With these changes, the behavior matches that of XFree86, at least as far as these sequences are concerned.
Created attachment 70464 [details] Patch for gtk+ to fix dead key sequences.
I failed to mention I haven't tested this patch, cause I'm missing glib2-2.0.6 in my laptop. I'll try it out tomorrow, and probably find out I shouldn't have reordered the entries :-(
Created attachment 70485 [details] Patch as applied
Tests out fine in 2.0.6-3