OT: klipper's misbeliefs [was: NEdit & KDE loss of selection problems]

[Joerg Fischer]

Here is a shortened extract from klipper's help:

  Clipboard/Selection Behavior

  [...]

  The X-Window System uses two separate clipboard buffers: the
  selection and the clipboard.  Text is placed in the selection buffer
  by simply selecting it, and can be pasted with the middle mouse
  button.  To place text in the clipboard buffer, select it and press
  Ctrl+X or Ctrl+C .  Text from the clipboard buffer is pasted using
  Ctrl+V or by selecting EditPaste.

  [This is a comment from the docbook sources of the klipper help.]
  <!-- Klipper can be used to set the clipboard mode for the whole of
  KDE.  The first mode will be familiar to Microsoft Windows and Mac
  users: Text is inserted into the clipboard using an application's
  cut/copy (or generally Ctrl+X and Ctrl+C respectively) function, and
  the application's paste (or generally Ctrl+V) function pastes the
  contents of this clipboard.

  The second mode will be more familiar to longtime UNIX users:
  Selected text is copied to this clipboard, and clicking the middle
  mouse button pastes the contents of this clipboard. -->


  Changing Clipboard/Selection Behavior

  In order to change clipboard/selection behavior, ...  Selecting
  "Separate clipboard and selection" makes the clipboard and selection
  function as completely separate buffers as described above.  With
  this option set, the option "Ignore selection" will prevent klipper
  from including the contents of the selection in its clipboard
  history ...  Selecting "Synchronize contents of the clipboard and
  the selection" causes the clipboard and selection buffers to always
  be the same, meaning that text in the selection can be pasted with
  either the middle mouse button or the key combination Ctrl+V , and
  similarly for text in the clipboard buffer.

  [A comment to this inside the docbook sources.]
   <!-- The Synchronize contents of the clipboard and the selection
   check box determines the clipboard mode.  If the box is selected,
   the clipboard functions in the UNIX mode; if not, the Windows/Mac
   mode is used. -->


And here are my views on this (correct me where I'm wrong):

I am no expert but IMO there are a few conceptual mistakes in the
preceding extract. 
The interisting mistake is the idea that X would have separate
clipboard buffers, one of them called 'selection'! 
Actually, there are no such buffers, even the clipboard can't be really
called a buffer, which can be easily seen by copying a selection in an
X client, then closing this client and trying to paste the clipboard
(which buffer?) into another client.

But I'm sure they know this, because this downside of the clipboard
implementation in X would be a justified reason to have a system-wide
tool like klipper buffering the clipboard.
(The downside of copying clipboard data to a 'buffer' is that doing so
with large chunks of data may affect the system's performance.)

What X has are selections: A primary selection called so, because there
is also a secondary selection, and, to my surprise, the clipboard
functionality is implemented as clipboard selection.  Perhaps this is
part of the cause for the conceptual mistakes the klipper folks do,
because selection[1] and clipboard are different functionalities in all
cases, that is, for Windows / Mac(Aqua) *and* for X, regardless of the
respective implementations of these two concepts.

Perhaps the purpose of selection is best explained with the help of a
GUI text editor, where there is only one true such editor for X ;-) 
If you do a selection there, the intention is to set the scope of
editing commands, like shifting or filling or like replacing a string
with another one (but only inside the selection).  For those more
familiar with console editors, the purpose of selection is that of a
region (emacs' terminology), which is just a part of the text between
two positions.  Of course, one can do also a copy/cut operation on the
selection, and it is only this single case[2] the user wants the
selection to go into the clipboard (or kill ring, if I recall that 
emacs feature correctly).
To summarize, a selection is just a small part of a bigger thing
selected out to do whatever you like with it (even putting it into the
clipboard).  A clipboard is for storing a piece of data with the sole
intention to include it somewhere else later on.

Therefore, a tool like klipper should only watch the clipboard, and
not the selection. --- Unfortunately, even if you select the options
to distinguish between selection and clipboard plus "ignore selection", 
the "prevent empty clipboard" option seems still to believe an empty
selection would be an empty clipboard.[3]

BUT why it should be *required* to do anything which results in a loss
of selection inside another X client like nedit, only in order to have
a clipboard buffer/history (without empty strings) I still don't
understand.

My speculation is that based upon wrong concepts the klipper folks are
also likely to ignore the rules for X clients, and then claim that all
other X clients would have mistakes or problems, and only klipper
would be right[4].


Jörg



[1] Actually, the primary selection, but let's forget about the
    seldomly used secondary selection for now--even though NEdit's
    mouse bindings do nice use of this--so, I say simply selection
    to the primary, because that's what the primary is for.
    
[2] The general X feature to paste the selection with the middle
    mouse button is a handy bonus, if you do *not* want to disturb
    the clipboard with this selection. (If you want the selection
    to go into the clipboard, you know what you have to do.)
    Notice, this convenience feature is obviously the other cause
    of believing X would have 'two separate clipboard buffers'.

[3] While the clipboard has some constancy, the selection is just
    constantly changing, and empty selections occur for technical
    reasons.
    
[4] There are some more folks complaining about klipper.