Red Hat Bugzilla – Bug 70995
Can't enter " easily with us_intl keyboard
Last modified: 2015-01-07 18:58:50 EST
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):
Steps to Reproduce:
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
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.
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
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
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
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
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 :-)
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
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