Please report this problem to the xfree86 mailing list as well,
to ensure that the xkb maintainers can hopefully fix this alleged problem
prior to the planned XFree86 4.3.0 gold release on Feb 27th.

Once the fixes are in CVS, I can update our snapshot to the latest, or to
4.3.0, etc. and provide a package update.  Please update this report when
the issue has been reported upstream, so I can track it.

Thanks.

Reported as
http://marc.theaimsgroup.com/?l=xfree86&m=104608144732256&w=2

Closing bug as UPSTREAM

Is this alleged problem still present in Red Hat Linux 9?  If so can you
re-report it upstream in the new bugzilla so it can be tracked, and then
provide the upstream bug URL here:

http://bugs.xfree86.org

I presume that the problem was just a configuration problem for you, and
that you have worked things out.  If this is not the case and the problem
still persists, please follow my instructions above of filing the bug upstream
and pasting the upstream bug URL here, and reopening this report, and I
will track it upstream as mentioned above

Closing as NOTABUG.

This seems to be an XEamcs issue (see the third comment in
http://list-archive.xemacs.org/xemacs-beta/200305/msg00331.html)

I have managed to hit this problem with RH9. There is an open bugzilla bug in
xfree86. Referencing it here. I posted all the details there including some
possible patches. 

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

Can this bug be re-opened?

Not sure why someone didn't report this upstream months ago as was
requested, as it is possible Ivan Pascal or someone could have
possibly come up with a solution by now if it had been reported
to them.

Now that it is reported upstream however, I will reopen this, and
change the resolution to UPSTREAM.  If Ivan or someone else develops
a solution for this issue for 4.3.0 which gets accepted into the
official XFree86 CVS repository in the xf-4_3-branch stable branch,
I will apply it to some test builds for a while and see if anything
breaks.  If these (hypothetical) upstream xf-4_3-branch fixes turn
out to be stable and not regress anything, I'll keep them in our
official builds for future erratum, etc.

Note that we will be tracking XFree86.org's official resolution to
this however, and if XFree86.org rejects the bug, then we will reject
it as well.  This issue _must_ be fixed in XFree86's stable 4.3.0
branch before I will consider including it in any of our future
4.3.0 releases, as Ivan is the expert in this area, and if he
rejects something, I consider his rejection as authoritative.

If the problem is fixed in some way in the head of CVS, but not
in the 4.3.0 branch, then it'll appear in our builds once 4.4.0
is released and we update to that.  I wont backport fixes from
CVS or 4.4.0 for this to 4.3.0 however unless Ivan considers them
safe enough to personally commit them to the xf-4_3-branch upstream
first.

Ok, reopening this to set the status to UPSTREAM to track this
in the upstream bug report.

Thanks for the update.

The upstream bug report was closed by XFree86.org with resolution
"NOTOURBUG", which indicates the issue is either a misconfiguration,
or a bug in emacs or somewhere else.

If this problem persists in a recent version of the OS distribution,
please file a bug report against emacs.  If you truely believe the
issue is within the X code, be sure to upgrade to Fedora Core 2 first,
and upgrade to the latest rawhide X.Org packages.  If the problem
persists, you can then file a bug report in X.Org bugzilla for a
secondary opinion from our new upstream X11 project.

If the experts in this area upstream believe this is not an X11
issue however, I have to defer to them as I am not an expert in
this area.

Closing bug as "NOTABUG" (we don't have a "NOTOURBUG" resolution)