Bug#909474: xterm: cannot copy to both CLIPBOARD and PRIMARY
On Mon, 24 Sep 2018, Thomas Dickey wrote: > 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? > 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. See above, but then, please treat it as a feature request. > 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’s 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 -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#909474: xterm: cannot copy to both CLIPBOARD and PRIMARY
On Mon, Sep 24, 2018 at 01:37:27PM +0200, Thorsten Glaser wrote: > 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. > 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. > 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). > 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). > 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 https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature
Bug#909474: xterm: cannot copy to both CLIPBOARD and PRIMARY
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 libfreetype62.8.1-2 ii libice6 2:1.0.9-2 ii libtinfo6 6.1+20180714-1 ii libutempter01.1.6-3 ii libx11-62:1.6.6-1 ii libxaw7 2:1.0.13-1+b2 ii libxft2 2.3.2-2 ii libxinerama12: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 xbitmaps1.1.1-2 Versions of packages xterm recommends: ii x11-utils 7.7+4 Versions of packages xterm suggests: pn xfonts-cyrillic -- no debconf information
