From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 Description of problem: When $LANG is set to "en_CA.UTF-8" and the keyboard layout is set for dead keys, such as the following setting: Option "XkbLayout" "us_intl" ...in XF86Config's InputDevice section, instead of double quotes showing up when <double quotes><space> are pressed in sequence, diaeresis are showing up. This is wrong. Double quotes are expected and required. This does not occure with the gnome-terminal, but only with xterm. Version-Release number of selected component (if applicable): XFree86-4.3.0-2 How reproducible: Always Steps to Reproduce: To reproduce: export LANG=en_CA.UTF-8 xmodmap - <<EOF keycode 48 = dead_acute dead_diaeresis apostrophe quotedbl EOF xterm& Now in the newly created xterm, press the double quote key (<shift-apostrophe>) followed by a space. Notice the character comming out. Altough it looks like one, its not a double quote. You can test it by doing: echo "This sentence should not appear double quoted." The normal behavior when surrounded by double quotes would output: This sentence should not appear double quoted. What you will get is: ¨This sentence should not appear double quoted¨ P.S. Its possible that bugzilla does not support internationalization, thus ? could show up instead of the diaeresis in the last output. Sorry, I can't do anything about that.
Most likely, this is not an xterm problem, but is either an xkb related bug, or some kind of misconfiguration of xkb. Please report this bug upstream to http://bugs.xfree86.org This is the fastest possible way to find a solution to xkb related issues. You may also wish to discuss the problem on xfree86 to see if anyone knowledgeable about xkb has any ideas. After reporting your bug upstream, paste the upstream bug report URL here and I will track it.
I guess this bug is a duplicate of bug #84802 (cfr. comment https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84802#c12).
*** This bug has been marked as a duplicate of 84802 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.