Bug 69628 - pasteboard delay when using xemacs remotely
pasteboard delay when using xemacs remotely
Product: Red Hat Public Beta
Classification: Retired
Component: xemacs (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2002-07-23 17:19 EDT by ctm
Modified: 2007-04-18 12:44 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-07-23 17:19:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description ctm 2002-07-23 17:19:53 EDT
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):


How Reproducible:


Steps to Reproduce: (newbie is running limbo)
1. ssh -n -X newbie xemacs&
2. Try C-kC-k

Actual Results:
Proper results, but only after a significant lag.

Expected Results:

Additional Information:
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
first time.
Comment 1 Trond Eivind Glomsrxd 2002-07-23 19:06:57 EDT
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.
Comment 2 ctm 2002-07-23 19:34:12 EDT
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

Note You need to log in before you can comment on or make changes to this bug.