Discussion:
Bug#909474: xterm: cannot copy to both CLIPBOARD and PRIMARY
Add Reply
Thorsten Glaser
2018-09-24 11:40:02 UTC
Reply
Permalink
Package: xterm
Version: 337-1
Severity: important
Tags: upstream

What passes as a “fix” for #901249 broke things in a different manner.
I’m filing as a new bug instead of reopening, though, because the
original report was “behaviour does not match documentation”, and this
one is “behaviour does not match expectation, documentation silent”.

Same scenario as in #901249.

I have two words on the command line, “foo” and “bar”.

I wish to have “foo” in CLIPBOARD and “bar” in PRIMARY.

I select “foo” with Shift. Now I can paste it with ^V in
a GUI application, but not with middle-click. Okaaay…

Then I select “bar” without Shift. I can paste it with
middle-click, but ^V does not paste “foo” any more.

Then I select “foo” with Shift again. Now middle-click
is dead again.

This is *not* why I have multiple clipboards in X11 and
go through pains of mapping them distinctly in xterm!


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

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.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-6
ii libfontconfig1 2.13.0-5
ii libfreetype6 2.8.1-2
ii libice6 2:1.0.9-2
ii libtinfo6 6.1+20180714-1
ii libutempter0 1.1.6-3
ii libx11-6 2:1.6.6-1
ii libxaw7 2:1.0.13-1+b2
ii libxft2 2.3.2-2
ii libxinerama1 2:1.1.4-1
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 xf
Thomas Dickey
2018-09-25 00:00:02 UTC
Reply
Permalink
Post by Thorsten Glaser
Package: xterm
Version: 337-1
Severity: important
hmm - no. This is "wishlist".

https://www.debian.org/Bugs/Developer#severities

for any feature request, and also for any bugs that are very difficult
to fix due to major design considerations.
Post by Thorsten Glaser
Tags: upstream
What passes as a “fix” for #901249 broke things in a different manner.
I’m filing as a new bug instead of reopening, though, because the
original report was “behaviour does not match documentation”, and this
one is “behaviour does not match expectation, documentation silent”.
Actually the documentation as such is oriented to the primary selection,
and describes how you could use the clipboard instead of the primary
selection. But using both at the same time was never intended (and
consequently there is no discussion of that in the manual).

Changing that would be a feature request.
Post by Thorsten Glaser
Same scenario as in #901249.
I have two words on the command line, “foo” and “bar”.
I wish to have “foo” in CLIPBOARD and “bar” in PRIMARY.
I was reminded of this, which may be useful.

keepClipboard (class KeepClipboard)
Specifies whether xterm-dev will reuse the selection data which
it copied to the keyboard rather than asking the clipboard for
its current contents when told to provide the selection. The
default is “false”.

For either primary or clipboard, xterm has only one source-buffer which
it uses to satisfy requests for selection content. That's been the case
"forever" (~1990). Since the previous bug report would inevitably lead
to complaints that they were the same content (or that selections were
"lost"), I did this

ensure that only one of PRIMARY and CLIPBOARD is owned by xterm at a
given time (Debian #901249).
Post by Thorsten Glaser
I select “foo” with Shift. Now I can paste it with ^V in
a GUI application, but not with middle-click. Okaaay

Middle-mouse pastes the primary OR clipboard selection for me
(using my test-package for #337 on Debian/testing).
Post by Thorsten Glaser
Then I select “bar” without Shift. I can paste it with
middle-click, but ^V does not paste “foo” any more.
Then I select “foo” with Shift again. Now middle-click
is dead again.
This is *not* why I have multiple clipboards in X11 and
go through pains of mapping them distinctly in xterm!
so... what exactly are the points to consider in a feature request?
I can think of a lot of possibilities :-)
--
Thomas E. Dickey <***@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net
Thorsten Glaser
2018-09-26 13:40:02 UTC
Reply
Permalink
Post by Thomas Dickey
hmm - no. This is "wishlist".
It would be if this were a completely new thing, a feature request.
But why would xterm allow binding different clipboards (cut buffers,
PRIMARY, SECONDARY, CLIPBOARD) to different copy/paste key/mouse
bindings if it did not support having multiple of them at the same time?
Post by Thomas Dickey
selection. But using both at the same time was never intended (and
consequently there is no discussion of that in the manual).
=20
Changing that would be a feature request.
See above, but then, please treat it as a feature request.
Post by Thomas Dickey
For either primary or clipboard, xterm has only one source-buffer which
it uses to satisfy requests for selection content. That's been the case
That=E2=80=99s not good.

My use case is this: in xterm, select two things (one to CLIPBOARD,
one to PRIMARY), then switch to a GUI application, and insert them
into different places. This greatly speeds up things, and from a
GUI application as sender, it already works (mark stuff, ^C, mark
other stuff, switch to receiving application).

Perhaps does this explain it better?

bye,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
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
Thomas Dickey
2020-01-14 00:30:02 UTC
Reply
Permalink
Patch #338 - 2018/12/09

revert the change which prevented concurrent ownership of different
selection targets, and instead modify selection storage so that
different concurrent requests for different selection targets will be
stored/retrieved independently (Debian #901249).
--
Thomas E. Dickey <***@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net
Loading...