[Annoyances] X-Windows Copy & Paste

[John Meacham]

> actually xterm  is extremely configurable in this regard:
> 
> this (in your .Xresources) turns off button 2 pastes and allows
> Shift-Insert - Paste PRIMARY
> Control-Insert - Paste CLIPBOARD if it exists, else PRIMARY
> 
> XTerm*VT100.Translations: #override\n<Btn2Up>:ignore()\n\
>      Ctrl <KeyPress> Insert:insert-selection(CLIPBOARD, PRIMARY)
> 
> adding a keybinding to copy the current PRIMARY selection to the
> CLIPBOARD (like an explicit cut in other apps) would be trivial.
> Xresoursces are quite the powerful tool.
> 
> perhaps these should be added as default bindings? (not the getting rid
> of middle button, but the CLIPBOARD actions) the fact that xterm
> can only work on PRIMARY by default does seem like a misfeature.

It occurs to me that since xterm does not allow modification of the text
being selected, there is no point in not setting CLIPBOARD on selection.
since the point of setting CLIPBOARD independently of PRIMARY is to
allow replacement of the selected text with a paste from another app.
i.e. no functionality is lost, but we gain the ability to paste X
selections into apps with explicit paste commands. 

It seems that the current clipboard.txt doesn't address this issue as
much as it should, in particular, as written, it implies the need for
two different pasting mechanisms and explicit copy actions in every app
whether they need it or not. I would like to propose the following
slight modifications/expansions of the clipboard.txt explaination. I
will use the word widget in the generic sense of any UI element which
can act as a source or destination of selections.

 * widgets which don't have explicit copy/paste actions or which cannot edit
   the selected buffer (xterm, web browsers (in the browser window), file
   viewers, static dialogs) should set both CLIPBOARD and PRIMARY on text
   selection. 

 * whenever CLIPBOARD is set, PRIMARY is set identically by all apps which
   set CLIPBOARD. This is implied by the current clipboard.txt saying that
   'copy' should set CLIPBOARD to a copy of PRIMARY, and is implied by the
   fact that you select something before you copy/cut it. However some apps
   don't need you to select text before performing a copy, they may have a
   keyboard shortcut to copy text or a button which copies something into
   the CLIPBOARD. this rule makes clear that they should set PRIMARY as
   well.

 * editor type widgets, with explicit copy/paste actions and the ability
   to modify the currently selected text (such as by selecting some text
   and pasting to replace it with the clipboard contents) will act as
   described in clipboard.txt, mouse selection sets PRIMARY, cut/copy
   sets PRIMARY and CLIPBOARD.

Rationale:

widgets which just set PRIMARY and have no mechanism for setting
CLIPBOARD (such as xterm's default config) cannot be used as the source
for an explicit paste. these widgets generally cannot edit the text of
their selection (hence the lack of explicit copy/paste commands) so do
not have a need to be able to select text without setting CLIPBOARD.
hence rule #1. 

Rule #2 guarantees that the ability to paste PRIMARY (probably but not
necessarily via middle-click) is always sufficient to accept pastes from
any other widget. This is important because the need to distinguish
between PRIMARY and CLIPBOARD buffers is unimportant for many types of
widget, it would be unacceptable to require 2 separate pasting
mechanisms in every app which wishes to accept pastes with the user
having to keep track of who supplied the paste to know how to utilize
it. This one is sort of obvious, but I have seen it violated on several
occasions, usually with the undesirable consequence that there is no
way to paste the selection into an xterm!

rule #3 is more a reiteration of what is currently said in
clipboard.txt the only difference is it explicitly applies rule 2 and
makes clear that some things don't change :)

Advantages:

mouse selection / middle-click (or some other PRIMARY paste mechanism)
is ALWAYS sufficient to paste to/from any other app or widget type
(editable or static) 

mousing/middle-clicking always works between apps as expected.

apps for which an explicit copy does not make sense (such as xterm) may
be used as the source of a explicit paste without the addition of an
extra step (explicit copy).

 * new users need only learn a single cut-paste mechanism,  it will always
be sufficient to transfer data between any 2 apps, other mechanisms are
optimizations and features and can be learned later as the user becomes
more familier with the system. *

 * users migrating from win/mac who always use explicit cut/paste when
available and mouse/middleclick otherwise will also have a good
experience. this idiom will also always work between any two apps as
expected. *

users will be happier because their pastes work properly :)

developers will be happier because they don't have to worry about
whether they are implementing the correct form of cut-n-paste :)

Recomendations:

add the previous to freedesktop.org somewhere, perhaps in clipboard.txt

make sure current apps and widget sets are in line with these rules (I
think they mostly should be.)

for XTerm (and other similar apps) I suggest the following be made the
default, this can be done by adding the lines to the
app-defaults file for XTerm

XTerm*VT100.Translations: #override\n\
        <BtnUp>:select-end(PRIMARY, CLIPBOARD) \n\
        Ctrl <KeyPress> Insert:insert-selection(CLIPBOARD, PRIMARY)\n\


any comments? I think these could improve the user experience a lot.
especially for those migrating from win/mac.

-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john at foo.net
---------------------------------------------------------------------------