Bug#901249: xterm: translation overrides for copy/paste do not work as documented

[Thorsten Glaser]

Package: xterm
Version: 333-1
Severity: normal

I was working on my .Xresources and found this quite crazy.
I could not select PRIMARY and CLIPBOARD independent of each
other. To reproduce, I chose to have *only* the lines from
the manual page…

*VT100*translations: #override \n\
~Shift~Ctrl<Btn2Up>: insert-selection(PRIMARY, CUT_BUFFER0) \n\
Shift~Ctrl<Btn2Up>: insert-selection(CLIPBOARD, CUT_BUFFER1) \n\
~Shift <BtnUp> : select-end(PRIMARY, CUT_BUFFER0) \n\
Shift <BtnUp> : select-end(CLIPBOARD, CUT_BUFFER1)

… loaded with “xrdb -merge filename”, with no .Xresources
at all, then I started two xterms, in one I selected, in
another, I ran xsel commands to discern what is the content
of PRIMARY and CLIPBOARD, respectively.

***@tglase-nb:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<> C<>
***@tglase-nb:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<foo> C<>
***@tglase-nb:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<bar> C<bar>
***@tglase-nb:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<foo> C<foo>

After the first command I selected “foo” without Shift.
⇒ as expected, PRIMARY gets assigned “foo”, CLIPBOARD is left alone
After the second command I selected “bar” with Shift.
⇒ unexpectedly, PRIMARY *also* gets “bar” in addition to CLIPBOARD
After the third line, I selected “foo” without Shift again.
⇒ unexpectedly, CLIPBOARD *also* gets “foo” in addition to PRIMARY


For comparison, here’s the same sequence of things on MirBSD,
with xterm 200 on XFree86:

***@blau:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<> C<>
***@blau:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<foo> C<>
***@blau:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<bar> C<bar>
***@blau:~ $ echo "P<$(xsel -p -o)> C<$(xsel -b -o)>"
P<foo> C<>

For that, I used this in .Xresources though:

*VT100*translations: #override \n\
Shift~Ctrl<KeyPress>Insert:insert-selection(PRIMARY, CUT_BUFFER0) \n\
Shift Ctrl<KeyPress>Insert:insert-selection(CLIPBOARD, CUT_BUFFER1) \n\
~Shift~Ctrl<Btn2Up>:insert-selection(PRIMARY, CUT_BUFFER0) \n\
Shift~Ctrl<Btn2Up>:insert-selection(CLIPBOARD, CUT_BUFFER1) \n\
~Shift<BtnUp>:select-end(PRIMARY, CUT_BUFFER0) \n\
Shift<BtnUp>:select-end(CLIPBOARD, CUT_BUFFER1)

(Actually, do I need a trailing \n or \n\ after the last line?)

Here, selecting “foo” without Shift again *clears* CLIPBOARD
instead of assigning to it. Still buggy.


I was considering not using cut buffers in xterm 333 on X.org:

*VT100*translations: #override \n\
Shift~Ctrl<KeyPress>Insert:insert-selection(PRIMARY) \n\
Shift Ctrl<KeyPress>Insert:insert-selection(CLIPBOARD) \n\
~Shift~Ctrl<Btn2Up>:insert-selection(PRIMARY) \n\
Shift~Ctrl<Btn2Up>:insert-selection(CLIPBOARD) \n\
~Shift<BtnUp>:select-end(PRIMARY) \n\
Shift<BtnUp>:select-end(CLIPBOARD) \n\

Anyway, from the above tests I concur that this never worked
as documented and still does not work as documented.


-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xterm depends on:
ii libc6 2.27-3
ii libfontconfig1 2.13.0-5
ii libfreetype6 2.8.1-2
ii libice6 2:1.0.9-2
ii libtinfo6 6.1+20180210-3
ii libutempter0 1.1.6-3
ii libx11-6 2:1.6.5-1
ii libxaw7 2:1.0.13-1+b2
ii libxft2 2.3.2-2
ii libxinerama1 2:1.1.3-1+b3
ii libxmu6 2:1.1.2-2
ii libxpm4 1:3.5.12-1
ii libxt6 1:1.1.5-1
ii xbitmaps 1.1.1-2

Versions of packages xterm recommends:
ii x11-utils 7.7+4

Versions of packages xterm suggests:
pn xfonts-cyrillic

[Thomas Dickey]

Post by Thorsten Glaser
Package: xterm
Version: 333-1
Severity: normal
I was working on my .Xresources and found this quite crazy.
I could not select PRIMARY and CLIPBOARD independent of each
other. To reproduce, I chose to have *only* the lines from

actually it was never intended that you could select both at the same time.
In #336, I've disallowed that.

[Thorsten Glaser]

Post by Thomas Dickey
actually it was never intended that you could select both at the same
time. In #336, I've disallowed that.

What does that even mean, wrt. the bug report?

bye,
//mirabilos

[Thomas Dickey]

----- Original Message -----
| From: "Thorsten Glaser" <***@mirbsd.de>
| To: "Thomas Dickey" <***@his.com>
| Cc: ***@bugs.debian.org
| Sent: Tuesday, September 18, 2018 2:56:26 PM
| Subject: Bug#901249: xterm: translation overrides for copy/paste do not work as documented

| Thomas Dickey dixit:
|
|>actually it was never intended that you could select both at the same
|>time. In #336, I've disallowed that.
|
| What does that even mean, wrt. the bug report?

The example you gave to show that the manual page was incorrect will no longer apply.

[Debian Bug Tracking System]

Your message dated Sun, 23 Sep 2018 07:20:13 +0000
with message-id <E1g3ygf-0000yJ-***@fasolo.debian.org>
and subject line Bug#901249: fixed in xterm 337-1
has caused the Debian Bug report #901249,
regarding xterm: translation overrides for copy/paste do not work as documented
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)

[Ondřej Kuzník]

I've had the following in my .Xprofile for a few years:
XTerm*VT100.translations: #override <Btn1Up>: select-end(PRIMARY, CLIPBOARD, CUT_BUFFER0)

Since the last upload, mouse selection has become highly unreliable and
it takes three selection attempts to actually get something into the
clipboard. On the first try it just seems to deselect immediately, the
second time text stays inverted, just sometimes never makes it into the
clipboard and sometimes an old selection makes it back into the
clipboard even when I've been able to paste the new one just before,
which is even more confusing.

Is this a bug with the new version or do I need to update the
translations to copy the selection so that it can be reliably used both
in middle clicks *and* Shift-Insert pastes?

Thanks,
Ondřej

[Thorsten Glaser]

reopen 901249
thanks

XTerm*VT100.translations: #override <Btn1Up>: select-end(PRIMARY, CLIPBOA=

RD, CUT_BUFFER0)

=20
Since the last upload, mouse selection has become highly unreliable and

Ouch. Yes, this is most likely caused by the change
=E2=80=9CEnsure that only one of PRIMARY and CLIPBOARD is owned by xterm
at a given time=E2=80=9D which not only does not fix my problem but also
causes this to no longer work.

On MirBSD, I have select-end(PRIMARY, CUT_BUFFER0) for ~Shift<BtnUp>,
and I guess this will then also no longer work.

Tom, please do revert that change, as it=E2=80=99s bogus *and* does not
address my initial problem (not being able to have xterm hold
*both* CLIPBOARD *and* PRIMARY but with *different* content).

Thanks,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: [phone] =E2=80=A2 Fax: [phone]
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg

[Debian Bug Tracking System]

Post by Thorsten Glaser
reopen 901249

Bug #901249 {Done: Sven Joachim <***@gmx.de>} [xterm] xterm: translation overrides for copy/paste do not work as documented
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions xterm/337-1.

Post by Thorsten Glaser
thanks

Stopping processing here.

Please contact me if you need assistance.

[Thomas Dickey]

Post by Thorsten Glaser
reopen 901249
thanks

Post by Ondřej Kuzník
XTerm*VT100.translations: #override <Btn1Up>: select-end(PRIMARY, CLIPBOARD, CUT_BUFFER0)
Since the last upload, mouse selection has become highly unreliable and

Ouch. Yes, this is most likely caused by the change
“Ensure that only one of PRIMARY and CLIPBOARD is owned by xterm
at a given time” which not only does not fix my problem but also
causes this to no longer work.

I'll take a look

Post by Thorsten Glaser
On MirBSD, I have select-end(PRIMARY, CUT_BUFFER0) for ~Shift<BtnUp>,
and I guess this will then also no longer work.
Tom, please do revert that change, as it’s bogus *and* does not
address my initial problem (not being able to have xterm hold
*both* CLIPBOARD *and* PRIMARY but with *different* content).

that one's still a wishlist (a new feature)