Bug#588785: #588785 xterm: consider supporting freedesktop.org style clipboard behavior

[Timo Juhani Lindfors <timo.lindfors@iki.fi>]

Thomas Dickey <dickey@his.com> writes:
> ...and it seems to work.  If you did not invoke the select-end, and
> started selecting again with the mouse, then that would discard the
> selection.

Odd.

$ appres XTerm

lists

...
*VT100.font6:   10x20
XTerm*VT100.Translations:       #override\n\
 Shift Ctrl <KeyPress> v:insert-selection(CLIPBOARD)\n\
 Shift<Btn1Down>:select-start()\n\
 Shift<Btn1Motion>:select-extend()\n\
 Shift Ctrl <KeyPress> c:select-end(CLIPBOARD)\n
*ptyInitialErase:       true
...

In the following I use http://lindi.iki.fi/lindi/xcutselprint to list
the contents of various selections and cut buffers:

$ xcutselprint
primary: "di1:~"
secondary: ""
clipboard: "http://vimeo.com/14522164";
cut0: "di1:~"
cut1: ""
cut2: ""
cut3: ""
cut4: ""
cut5: ""
cut6: ""
cut7: ""

# I select my username from the shell prompt inside xterm

$ xcutselprint
primary: "lindi"
secondary: ""
clipboard: "http://vimeo.com/14522164";
cut0: "lindi"
cut1: ""
cut2: ""
cut3: ""
cut4: ""
cut5: ""
cut6: ""
cut7: ""

# I hit ctrl-shift-c

$ xcutselprint
primary: "lindi"
secondary: ""
clipboard: "http://vimeo.com/14522164";
cut0: "lindi"
cut1: ""
cut2: ""
cut3: ""
cut4: ""
cut5: ""
cut6: ""
cut7: ""

=> Clipboard contents did not change at all. Are you sure clipboard
contents changed in your case and not just the primary selection?

> I compiled xterm with (--enable-trace) debugging traces to check if I
> might see anything odd, e.g., events passing into the keyboard input
> from an incomplete coverage of the translations, and don't see any of
> that.

I'm using xterm 261-1.