Re: Strange delays when running remotely

I'm going to leave the default on "correct behavior", and work on PROBLEMS and the FAQ. Proposed FAQ follows, comments requested.

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.

------------------------------------------------------------------------