+@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
+Cut and Copy, respectively, buttons on the toolbar.
+
+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 usually
+don't need to customize the complementary @code{interprogram-paste-function}
+to @code{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
+@code{x-selection-strict-motif-ownership} to nil, but this means you will
+only intermittently be able to paste XEmacs kills to Motif applications.
+