+@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.
+