Description of problem: With LANG is set to en_CA.UTF-8 keyboard handling makes standard editors unusable. 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 European languages.) 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 us layout.
> 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 really special). 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 /etc/X11/XF86Config-4
> 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. and 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.