Red Hat Bugzilla – Bug 80703
editors useless on gnome desktop
Last modified: 2007-04-18 12:49:22 EDT
Description of problem:
With LANG is set to en_CA.UTF-8 keyboard handling makes standard editors
After starting emacs or gvim one can pound on a key with " and ' any numbers
of times without causing any reaction at all. If one will start
'emacs -nw' in a terminal window then hitting " twice is doing something
but nothing expected (it is easier to see that than describe). 'vi' started
in a terminal window _pretends_ to insert " when " is hit twice but this is
really not that character which can be seen in attempts to search for quotes
already existing in a file; they fail.
After switching to a text console apparently one can use an editor
(I did not run extensive tests) but such workaround is plain ridiculous.
Don't see how gnome is involved (gnome-core doesn't even exist anymore).
This would be a keymap or input method problem afaik. It's possible I suppose
that the gnome keyboard switcher applet messes that up, if you're running it, but
you'd have to check whether things work if you run under twm etc.
Does emacs or vi even support UTF-8?
What terminal are you running in? What keyboard layout are you using?
(Emacs and vi both have UTF-8 support; the Emacs support is
pretty awful, but it should be good enough for French and other
For emacs-not-in-a-terminal, or gvi, this would be a XFree86
issue - the compose hanlding for Xlib was changed a bit recently
and various bugs have shown up.
If emacs or vi is misbehaving inside a gnome-terminal, that would
be a different problem, but without knowing your keyboard layout,
it's hard to know exacty what sort of different problem.
I do not know what is responsible for a totally broken behaviour.
The bug has to be filed somewhere and I only report what I observe.
If you think that this is a bad component then change it.
My installation is using "US keyboard" and "en_CA" locale. Nothing
"exotic". Whatever anaconda dumped on my hard drive is there.
Does en_US.UTF-8 work? AFAIK, there should be absolutely no difference
between en_US.UTF-8 and en_CA.UTF-8 for keyboard handling.
> Does en_US.UTF-8 work?
I tried few different encodings starting things like
'( env LANG=en_US.UTF-8 emacs )' and bunch of other other variants (vi, gvim,
'emacs -nw') with different LANG settings which included and excluded UTF-8.
I could not find even remotely sane behaviour.
I hate to ask this question, but since nobody else has reported
any issues (at least that I've seen), and it should be really
obvious if the " key doesn't work, are you sure your keyboard
is working correctly?
Or - could you have accidentally selected the us_intl keyboard
rather than the us keyboard during the install? The us_intl keyboard
will be quite strange in behavior for someone expecting a standard
> are you sure your keyboard is working correctly?
I would think so. :-) The report in which you can see incriminated
characters is typed in on the same machine and the same keyboard but
while running a system based on 7.3 distro. It is a "dual boot" setup.
I also mentioned that I can use a console and edit so I think that we
can safely eliminate my keyboard (Logitech Deluxe 104 - once again nothing
IIRC 'gvim' blinks for a short moment something on a status line about
"XIM extenstions", whatever that may be. In the meatime I rebooted
few times between my "work", and workable, system and "Phoebe" installation
and this also nothing changed.
The keyboard layout isn't your keyboard, but a config option. (What
you selected on install, usually, but it could be changed at other
points.) You should be able to see what it is by looking at
> You should be able to see what it is by looking at /etc/X11/XF86Config-4
This file does not exist. :-) But in XF86Config I can see
# File generated by anaconda.
Option "XkbRules" "xfree86"
Option "XkbModel" "pc105"
Option "XkbLayout" "us_intl"
Why "us_intl" I am not so sure.
I can try later to reconfigure the whole X from scratch.
Indeed, after reconfiguring "XkbLayout" from "us_intl" to "us" the problem
disappears. Why anaconda stick the first one in XF86Config I am not sure.
It could be that in a "user friendly" interface I turned it on accidentally.
So is the resolution for this one 'user goofup', or is there something
to investigate here still?
I guess that this can be closed (if ending up with one of "official"
keyboard mappings qualifies as "goofup").
Well all the official mappings can't work for all keyboards, if any mapping
would work with any keyboard you wouldn't have to choose one.
I do think the keyboard selection UI could use some love (naming the keymaps
something better for a start), but I would say it's currently working as intended.