I've watched this get reported before, changed upstream, other bugs get
reported upstream due to those changes, and it got changed again at least
once, if not twice.

I am not an authority or an expert on what is the /correct/ solution,
and I won't pretend to be.  I do however consider XFree86.org to be
the experts in this area though, and what they decide is what we will
ship.  So any problems in this area should be reported directly to
XFree86.org so that the proper process by the experts in this area
can be taken.

Red Hat is not going to ship customized changes to these files and then
maintain them indefinitely.  Please report upstream to xpert@xfree86.org
and xfree86@xfree86.org.

This is better in 4.2.99.901-20030213.0, but it is still impossible to generate
", double acute accent and cedilla.  Not being able to enter " easily (i.e.,
having to resort to Alt-Shift-" instead of quote-blank or quote-quote), seems
like a very serious problem to me.

lxo, do you have the upstream bug report URL?  It could help me to locate
the fix.

It was never reported upstream as a bug.  Patches were sent and integrated in
the tree, but I understand we'd intentionally decided to not have the patches in
our tree, because of the risks of problems that would affect all UTF8 users.  I
may misremember and think what happened before 9 actually happened before 8.0,
though.

Ah.  Well, if there are fixes in current X CVS that someone can point out,
I'd be willing to review them for possible inclusion in Cambridge now.

Confirmed, the patch is still in rawhide:
# Revert CVS commit, as we can't verify it to be regressionless at this
# stage, but will apply it once we've seen widescale testing.
#
#    952. A more complete set of dead accent/space compose sequences, add
#        <Multi_key> <slash> for letters with a "stroke", and add some
#        combos for exponent characters, katakana voiced sounds, etc to
#        the en_US.UTF-8 compose file (#5646, David Monniaux).
Patch9102: XFree86-4.3.0-revert-en_US.UTF-8-Compose.patch
# This patch is a smaller version of the original 952 commit believed to
# be safer for now, but unapplied currently
Patch9103: XFree86-4.3.0-en_US.UTF-8-Compose-safer.patch

I see, however, that the relevant parts of David's patch seem to have been
preserved in the 9103 patch.  I also see that, even in the followup patch that
David posted, he doesn't address the problem of double quotes :-(  Looks like
I"m going to have to kick in and do something about it.  It surely doesn't help
that the patches I posted to the xfree86 mailing list haven't got any response,
nor made it to the archives.  Apparently they silently reject e-mail from me,
for some reason I can't figure out.

Woohoo, it seems that my patch to address my last issues with the UTF8 compose
rules actually made it somehow.  It would be *very* convenient to have it in our
release. 
http://cvsweb.xfree86.org/cvsweb/xc/nls/Compose/en_US.UTF-8.diff?r1=1.8&r2=1.9

%patch9102 -p0 -R -b .revert-en_US.UTF-8-Compose
%patch9103 -p0 -b .en_US.UTF-8-Compose-safer

Hrm, I thought I had disabled that now, to provide stock XFree86's compose.
Looks like I did not.  I meant to do that at the outset of cambridge.  ;o/

I'm going to change this right now.

This is almost completely fixed, but the patch to re-introduce a relatively
simple way to generate the " character with us-intl kbd is still missing.  Could
we consider it a blocker for Cambridge, given how simple the patch is, and that
it's been in upstream CVS for such a long time? 
http://cvsweb.xfree86.org/cvsweb/xc/nls/Compose/en_US.UTF-8.diff?r1=1.8&r2=1.9

*** Bug 101588 has been marked as a duplicate of this bug. ***

Patch applied to 4.3.0-26 in rawhide.

Confirmed fixed, thanks!

Using rawhide XFree86-4.3.0-40 makes it possible to make quotdbl. 
But I still can't find a way to make ccedilla. Even with the coma composition. 
 
I was browsing the xkb files and found many micracles the Multi_key and ALTGR 
keys can generate. But I can't find a way to use it. right-ALT is not MultiKey or 
ALTGR in my en_US.UTF-8, us_intl+deadkeys, Generic 105k keyboard. 
 
Where is ALTGR or MultiKey in RH9 ?? 
Same problem as reported in bug 122 at bugzilla.xfree86  
(http://bugzilla.xfree86.org/show_bug.cgi?id=122)  
 

I think I found a solution for this, as I described in 
 
http://bugzilla.xfree86.org/show_bug.cgi?id=122 
 
Add the following line to xkb/symbols/us_intl: 
key <RALT> {    [ Mode_switch,  Multi_key       ]       };  
 
Now I can generate ç (ccedilla) with right-ALT + comma + c 

Since this change would affect all users of us_intl and not just
pt_BR users, it is too risky to consider adding to 4.3.0 at this
stage, as we've had it this way through all betas which included
4.2.99.x and 4.3.0, and now also in at least 3 operating system
releases which include 4.3.0.  Changing this now would introduce
unnecessary risk of regression, of which some previously made
changes were shown to regress.  Our 4.3.0 releases need to remain
stable in order to provide a single source of 4.3.0 to be used
as erratum for all Red Hat OS products throughout their support
lifecycle.

There is one way that I would be willing to reverse this decision
however.  If XFree86.org is willing to consider this change low
risk and stable enough for usage in 4.3.0, they will apply it to
xf-4_3-branch - the CVS stable branch.  If they're unwilling to
apply it to their stable branch, then there are risks involved which
they are unwilling to take, and it isn't reasonable for us to take
on such risks either.

Users experiencing this problem (in any keyboard layout) are
encouraged to report their problems in upstream bugzilla as has
been done here, and also to test a full install of XFree86 CVS head
while it is still in development, so that 4.4.0 does not contain
such problems.  For the current time, people would have to build
XFree86 CVS from source as there are no rpm packages available yet.

I'm defering this until I fork the src.rpm for 4.3.99.x or 4.4.0
for rawhide development in the future.  This report should be
reopened at that time, and someone who is affected by the problem
should test it and report back wether the problem persists, as
well as updating the upstream report, in hopes XFree86.org fixes
it in time for 4.4.0, or in the stable xf-4_4-branch after the
release of 4.4.0.

Changing status to DEFERRED

Actually, I just realized that aoliva reported this bug and has
declared it is fixed.  So I'm leaving the bug status alone, unless
aoliva can confirm the behaviour reported by Avi, and considers
it the same bug.

It might be best instead to file a new bug report, as the two
issues seem similar but different.  I can then set the status
of that report to UPSTREAM, which would be preferable over
DEFERED, as UPSTREAM bugs get scanned more often for upstream
changes in indicated URLs to bugzilla.

aoliva:  Any comments you'd like to add about this issue here
would be appreciated.

Sorry for the confusion.

TIA

AFAIK us_intl already has dead keys.  Keyboard Layout Switcher uses
this cmd to enable dead keys for me: gkb_xmmap us_intl

At this point, AltGR works as MultiKey.  This is with Fedora
Core/rawhide.  I don't quite remember whether this was already fixed
in Shrike.

Ok cool.  The good news is that XFree86 is being erratum'd for RHL 9
soon which contains all bug fixes that are in Fedora Core 1, and
possibly a few more, so that will end up in Shrike soon enough too.

Thanks lxo

I think that the *real* bug is that MultiKey or AltGr was not
configured, So users couldn't make compositions. Tested on Rawhide
XFree86-4.3.0-42.

As far as I understand, this fix will not affect european (the ć
users) us_intl users. It will only add new keys. But I understand the
risk.

I'm not sure if only reporting the bug on bugzilla.xfree86 will make
them apply the patch. Anyway I trust more in you guys.

Anyway, I posted an update to the bug. Instead of that line I included
here, a more generic solution is to include:

     include "compose(ralt)" 

Thank you,
Avi

I don't quite understand the differences between my and your keyboard
setups, but I certainly don't need any changes to enable AltGR to be
used as a Compose key.  Can you provide more details on how you've set
things up?

I have 2 computers acting exactly the same way:

- A regular PC with a regular US keyboard
- An IBM laptop with a US keyboard

I have the following configuration in my KDE system:

- LANG=en_US.UTF-8
- Generic 101/102/104 or 105 (Intl) PC (tested all this configs)
- Layout US-English with deadkeys
- Primary variant = basic

And in both the cedilla doesn't work.

It looks like Xfree folks accepted the patch. See 

   http://bugs.xfree86.org/show_bug.cgi?id=122

I don't see any indication the patch was accepted.  I see David
asking people to test current CVS to see if this is even an issue
in current CVS.

Even if the patch, or any other patch gets accepted into CVS head
for this perceived issue, as I indicated above, I have no intention
of applying any patch in our 4.3.0 rpm packages, unless XFree86.org
checks any fixes into their xf-4_3-branch stable branch of 4.3.0
CVS.  If they do not apply any fix in xf-4_3-branch, then there is
no way it is getting into my rpm packages.

To Alexandre Oliva. 
 
How can it be that I'm setting many many machines with intl keyb, observing the 
same problem and you don't? 
Maybe you are using Gnome and I KDE, and Gnome installs some keyb extensions? 
I don't use to install Gnome, so I can't test. Can you try to reproduce it there with 
KDE? 
 
I wish to hear your comments regarding one of my last postings about my keyboard 
configurations. 

Could you guys please continue the discussion in email perhaps?
Bugzilla isn't the best place to continue a tech support type of
problem on a closed bug report that is confirmed fixed by the
reporter of the bug.

Thanks.

I'm getting no response for this bug. 
It is slowing donw the adoption of a Linux desktop by some users in 
my company. The solution is available but problem still remains. 

The response is:  This bug, as filed by Alexandre Oliva, is FIXED
in RAWHIDE a long time ago, and Alexandre has positively confirmed
this fix several times.  This means that this bug is fixed and is
a done deal, and will not receive further attention at all, unless
Alexandre sees a regression in the future and thinks the bug has
returned.

Your problem will not be addressed by Red Hat ever, unless it is
addressed by XFree86.org upstream in a new XFree86 release.  

I consider this issue 100% closed, permanently.

*** Bug 90443 has been marked as a duplicate of this bug. ***