Bug 80703

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.