Bug 188357 - deadkeys don't work with XIM
Summary: deadkeys don't work with XIM
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: scim
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-04-08 11:58 UTC by Alexandre Oliva
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-08-14 01:18:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexandre Oliva 2006-04-08 11:58:14 UTC
Description of problem:
I've had a number of input-related problems lately, apparently most of them
related with the latest scim builds.  Most of them appear to have already been
fixed, but this one remains, and it's highly annoying.

Running the latest builds of GNU Emacs and XEmacs locally, with the US
International keyboard layout, everything works just fine.

However, if I run vncviewer on this same box and connect it to the VNC server
module loaded into the X process, I get the problem I'm going to describe.  I
haven't tried vino on the server, mainly because it doesn't handle well (or at
all?) differences between the keyboard maps of the server and the client, which
Xvnc does.  The machine I normally connect to has a br-abnt2 keyboard, but I
believe that's irrelevant.

It is probably worth pointing out that I had to downgrade to
xorg-x11-server-Xorg-1.0.1-9 in order for Xvnc to work, but that's a separate bug.

Anyhow, the problem is that using dead-keys followed by blanks produce different
effects depending on whether *emacs gets the input from the local keyboard or
from vnc.

When getting input from the local keyboard, on both machines, both GNU Emacs and
XEmacs correctly take the sequence dead_diaeresis + space as a quotedbl, whereas
over vnc they both behave differently.

XEmacs interprets the same sequence as diaeresis, a behavior I'd observed many
months ago, that could be worked around by setting LANG=en_US instead of
en_US.UTF-8, but that apparently went away by itself; I had a bug report on
that, but I don't have the bug number handy.

GNU Emacs interprets the same sequence as an error, and just emit a blank.  This
behavior is new to me, although I haven't used GNU Emacs regularly in the recent
past.

GTK applications always generate " for the same sequence.

Version-Release number of selected component (if applicable):
emacs-21.4-14
xemacs-21.4.19-4
scim-1.4.4-13
xorg-x11-server-Xorg-1.0.1-9
vnc-server-4.1.1-36

How reproducible:
Every time

Steps to Reproduce:
1.Set up a server box with br-abnt2 or us-intl keyboard and Xvnc loaded into the
X server
2.Test that dead_diaeresis followed by blank generate quotedbl in GNU Emacs and
XEmacs locally
3.Connect another box to it over VNC
4.Test the same key sequence on both
  
Actual results:
2 works, 4 does not.

Expected results:
As of one week ago or so, it worked the same on both.

Additional info:

Comment 1 Alexandre Oliva 2006-04-08 12:10:26 UTC
I failed to mention that the stream of events, as reported by xev, is
essentially identical in both cases.  The only significant difference is that of
the key codes, but the interpreted keysyms are the same.

Comment 2 Alexandre Oliva 2006-04-08 12:25:50 UTC
It actually gets worse.  In gtk apps such as gnome-terminal, with the us-intl
keyboard configuration, dead keys on the local keyboard followed by blank
produce no input whatsoever.

Comment 3 Jens Petersen 2006-04-11 03:04:00 UTC
Any better with scim-1.4.4-14?

Comment 4 Alexandre Oliva 2006-04-11 03:19:09 UTC
The problem in comment #2 appears to be fixed, but the main bug is still
present.  GNU Emacs and XEmacs are still unusable in configurations that have
dead keys, except now it's in both local and connections and over vnc. 
dead_diaeresis followed by blank produces a blank in GNU Emacs and a diaeresis
in XEmacs, where it used to, and still should, produce quotedbl on both, just
like it does on GTK apps, and doubling the dead keys, that used to produce the
non-dead corresponding accents, now is taken as a (possibly infinite) stream of
dead-key events, also unlike GTK apps, that produce the actual accents.

Comment 5 Jens Petersen 2006-04-12 03:20:35 UTC
Could you try uninstalling scim and see if that makes a difference?
I don't think there have been any major changes related to this
in the scim package recently.

BTW most Asian users prefer to turn off XIM in Emacs and XEmacs fwiw.

Comment 6 Alexandre Oliva 2006-04-12 04:24:26 UTC
unset XMODIFIERS before starting Emacs or XEmacs makes them both functional, so
I'm pretty sure rpm -e scim would fix it until I next run my script that
installs everything that's available in rawhide :-)  

I know the regression became apparent recently, but it might be related with the
fact that scim was completely disabled before.

Comment 7 Jens Petersen 2006-04-27 03:29:31 UTC
BTW this is most likely a limitation of Xlib XIM.

Comment 8 Jens Petersen 2006-05-12 09:48:18 UTC
Now, I'm confused - deadkeys seem to be working ok for me with XIM in Emacs
(on my fc5 box with scim from FC devel).

Comment 9 Leon Ho 2006-07-12 01:42:11 UTC
Alexandre: Can you confirm if FC devel's scim fix this problem?

Comment 11 Alexandre Oliva 2006-08-01 03:12:06 UTC
I'm afraid I can't.  My wife rebooted her rawhide-tracking box the other day,
and now scim is getting in the way of proper functioning of dead keys on both
GNU Emacs and XEmacs, even though scim says it's disabled for the English
keyboard layout :-(

Comment 12 Jens Petersen 2006-08-07 09:41:54 UTC
Thanks for reporting that: seems it was caused by excluding the
English/European keyboard engine by default.  Defaults should be fixed
in scim-1.4.4-30.fc6, but existing users may have to add enable it by
hand in scim-setup.

Comment 13 Jens Petersen 2006-08-14 01:18:11 UTC
Closing.  Please re-open if there are still problems.

Comment 14 Alexandre Oliva 2006-08-14 01:23:09 UTC
It seems to be good now.  I changed my .profile to re-enable scim a few days ago
and forgot to report back since everything worked just fine :-)  Thanks!


Note You need to log in before you can comment on or make changes to this bug.