Matt> Forgive me if this is a common question. I didn't see it in Matt> the FAQ. It was added for 21.4.9. ;-) It's not in the Web-based version either, sorry. Matt> kill-region takes an inordinately long time, depending on Matt> the size of the region and (I think) the speed of the link. ＠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: ＠table ＠strong ＠item Primary selection a transient selection that gets replaced every time a new selection is made ＠item Secondary selection for "exchanging" with the primary selection ＠item Cut buffers a clipboard internal to the X server (deprecated) ＠item Clipboard selection a selection with a notification protocol that allows a separate app to manage the clipboard ＠end table 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. There are a number of workarounds. The most effective is to use a special command to do selection ownership only when you intend to paste to another application. Useful commands are ＠code{kill-primary-selection} and ＠code{copy-primary-selection}. These work only on text selected with the mouse (probably; experiment), and are bound by default to the ＠kbd{Cut} and ＠kbd{Copy}, respectively, buttons on the toolbar. ＠code{copy-primary-selection} is also bound to ＠kbd{C-Insert}. You can yank the clipboard contents with ＠code{yank-primary-selection}, bound to the ＠kbd{Paste} toolbar button and ＠kbd{Sh-Insert}. If you are communicating by cut and paste with applications that use the primary selection, then you can customize ＠code{interprogram-cut-function} to ＠code{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 also need to customize the complementary ＠code{interprogram-paste-function} to ＠code{nil}. (Otherwise XEmacs-to-XEmacs pastes will not work correctly.) You may get some relief on Motif by setting ＠code{x-selection-strict-motif-ownership} to nil, but this means you will only intermittently be able to paste XEmacs kills to Motif applications. Thanks to Jeff Mincy and Glynn Clements for corrections. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsuk

Matt Simmons wrote: Yes. That will make C-w, M-w, C-y etc internal to XEmacs. To cut/paste to/from other applications, use C-insert/Sh-insert. -- Glynn Clements <glynn.clements(a)virgin.net&gt;