Description of Problem:
Using xemacs on a limbo machine from an RH 7.3 machine, I get massive (several
seconds) delays when cutting in Xemacs.
Version-Release number of selected component (if applicable):
Steps to Reproduce: (newbie is running limbo)
1. ssh -n -X newbie xemacs&
2. Try C-kC-k
Proper results, but only after a significant lag.
This problem appears to be well known on the Xemacs list, but since I only
ran across it when I started using limbo, I assume it might be of interest
to someone @ Red Hat.
(setq x-selection-strict-motif-ownership nil)
is a workaround that appears to make the lag go away in all but the first cut,
but with the side effect that pasting from Xemacs into another app may fail the
I think I'll refer to the defaults for this, as the handling of the X protocol
is not something I want to override by default.
My original bug report didn't explicitly mention it, but before the upgrade to
limbo, there was no such lag. I believe my upgrade was from 7.3.
Although by some definition it's not a bug, it is a significant unexpected
change in behavior that makes Xemacs very hard to use remotely (at least over a
340Kb/sec DSL connection).
Maybe the spec file can be jiggered to put a comment in upgrade.log that
explains this new behavior and includes the workaround. It doesn't matter to me
personally. I just suspect that without eye-catching documentation, this one
will bite a bunch of people who will all have to independently find the same