Red Hat Bugzilla – Bug 69628
pasteboard delay when using xemacs remotely
Last modified: 2007-04-18 12:44:25 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): 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.
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 workaround.