Re: Strange delays when running remotely

Andy> So I don't think this is true, and we should probably come Andy> to some sort of consensus about what the various problems Andy> really are and put it in PROBLEMS. What I said is true for Xlib. For Motif, you just lose, lose, lose. I'm not worried about Motif; we can't fix it (at least not in 21.4). We can at best provide a few very unsatisfactory alternatives. The problems are known: Motif clipboard ownership _by design_ requires a lot of X protocol. If you don't do the protocol, the clipboard content doesn't change, so pasting from XEmacs doesn't work. If you do the protocol, it takes a long time if protocol is slow. Some work was done on trying to limit the amount of protocol that needs to be done by evaluating the selection lazily, but that was broken, too. Maybe somebody should go see how Mozilla does this on Motif. People using remote connections could check to see how snappy other applications are about cut and paste. If you find an open source (GPL-compatible license, s'il vous plait) app with good performance, let us know. Maybe we can use its cut code. Andy> IMO we should consider making the default nil rather than t. We've tried that, at some point in 21.2, and we got a lot of complaints about inability to paste from XEmacs to Motif apps, especially web browsers. This gets _worse_ over time, not better, as more and more apps and whole toolkits adopt the Motif/Windows clipboard approach rather than the X selection approach. And more people expect cut/paste etc to Just Work. On this, we're damned if we do, damned if we don't. Heck, we even get complaints from people who have complained about one aspect of the problem, and then don't like the alternative any better. I'm going to leave the default on "correct behavior", and work on PROBLEMS and the FAQ. Proposed FAQ follows, comments requested. Note: it's in "Section 3: Customization" because Subsection 3.10 is "Text Selections." Suggestions for a better place to put it welcome. PROBLEMS will just refer to the FAQ, both Info and a web URL. ------------------------------------------------------------------------ ＠node Q3.10.6, , Q3.10.5, Customization ＠unnumberedsubsec Q3.10.6: Why is killing so slow? This actually is an X Windows question, although you'll notice it with keyboard operations as well as while using the GUI. Basically, there are four ways to communicate interprogram via the X server: ＠c This should be an ＠table. Primary selection: a transient selection that gets replaced every time a new selection is made Secondary selection: for "exchanging" with the primary selection Cut buffers: a clipboard internal to the X server (deprecated) Clipboard selection: a selection with a notification protocol that allows a separate app to manage the clipboard The cut buffers are deprecated because managing them is even more inefficient than the clipboard notification protocol. The primary selection works fine for many users and applications, but is not very robust under intensive or sophisticated use. In Motif and MS Windows, a clipboard has become the primary means for managing cut and paste. These means that "modern" applications tend to be oriented toward a true clipboard, rather than the primary selection. (On Windows, there is nothing equivalent to the primary selection.) It's not that XEmacs doesn't support the simple primary selection method, it's that more and more other applications don't. So the slowdown occurs because XEmacs now engages in the clipboard notification protocol on ＠emph{every} kill. This is especially slow on Motif. With most people running most clients and server on the same host, and many of the rest working over very fast communication, you may expect that the situation is not going to improve. If you are communicating by cut and paste with applications that use the primary selection, then you can customize `interprogram-cut-function' to nil, restoring the XEmacs version 20 behavior. How can you tell if a program will support this? Motifly-correct programs require the clipboard; you lose. For others, only by trying it. You usually don't need to customize the complementary `interprogram-paste-function' to nil; presumably you're willing to wait for a paste from another program if delays only happen when you specifically request a paste. You can get some relief on Motif by setting `x-selection-strict-motif-ownership' to nil, but this means you will only intermittently be able to paste XEmacs kills to Motif applications. ------------------------------------------------------------------------ -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py