Bug 69628 - pasteboard delay when using xemacs remotely
Summary: pasteboard delay when using xemacs remotely
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: xemacs
Version: limbo
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-07-23 21:19 UTC by ctm
Modified: 2007-04-18 16:44 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2002-07-23 21:19:57 UTC


Attachments (Terms of Use)

Description ctm 2002-07-23 21:19:53 UTC
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):

xemacs-21.4.8-8

How Reproducible:

Trivially.

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

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 23:06:57 UTC
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 23:34:12 UTC
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
workaround.



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