Re: xterm PRIMARY and CLIPBOARD selection [was: Re: Copy from Firefox and paste into Terminal with Vim]
Stefan Monnier wrote: > > I have not said it is more “standard for terminals”, I have that it > > is more “standard” fullstop. It is more standard by the virtue of > > having worked for decades, C-Ins S-Ins S-Del existed way before the > > C-C C-V C-X tryptich, and still working today in most contexts. > > Indeed, IIUC these key bindings were part of the CUA standard: > https://en.wikipedia.org/wiki/IBM_Common_User_Access Indeed and CTRL-C & friends first appeared as Apple-C on the Lisa, it seems and were appropriated by Microsoft after a while: https://www.howtogeek.com/804030/the-origins-of-ctrlc-ctrlv-ctrlx-and-ctrlz-explained/
Re: xterm PRIMARY and CLIPBOARD selection [was: Re: Copy from Firefox and paste into Terminal with Vim]
On 07/02/2024 19:20, Nicolas George wrote: Max Nikulin (12024-02-07): It may be a convention for applications other than terminals, however I am unsure what "standard" means for terminals. I have not said it is more “standard for terminals”, I have that it is more “standard” fullstop. It is more standard by the virtue of having worked for decades, C-Ins S-Ins S-Del existed way before the C-C C-V C-X tryptich, and still working today in most contexts. Terminal application should leave standard hotkeys for applications running in terminals. It is the reason why modern terminals use [Ctrl+Shift+c] and [Ctrl+Shift+v] instead of conventional [Ctrl+c] and [Ctrl+v]. That is why I am against idea of adding [Ctrl+Insert] to xterm bindings. In Emacs C- is bound to `kill-ring-save'. Works for me. The author of XTerm is quite reactive if you can explain the issue clearly, I am not surprised it was fixed. My impression, it was a decision to support only single storage for handling selection. I like that it was changed.
Re: xterm PRIMARY and CLIPBOARD selection [was: Re: Copy from Firefox and paste into Terminal with Vim]
> I have not said it is more “standard for terminals”, I have that it is > more “standard” fullstop. It is more standard by the virtue of having > worked for decades, C-Ins S-Ins S-Del existed way before the C-C C-V C-X > tryptich, and still working today in most contexts. Indeed, IIUC these key bindings were part of the CUA standard: https://en.wikipedia.org/wiki/IBM_Common_User_Access Stefan
Re: xterm PRIMARY and CLIPBOARD selection [was: Re: Copy from Firefox and paste into Terminal with Vim]
Max Nikulin (12024-02-07): > It may be a convention for applications other than terminals, however I am > unsure what "standard" means for terminals. I have not said it is more “standard for terminals”, I have that it is more “standard” fullstop. It is more standard by the virtue of having worked for decades, C-Ins S-Ins S-Del existed way before the C-C C-V C-X tryptich, and still working today in most contexts. > Thanks, it seems, it works in bookworm. Several years ago xterm did not > support ownership of independent CLIPBOARD and PRIMARY simultaneously. It > was a workaround for the following scenario: > > - select some text > - copy it to CLIPBOARD > - select another fragment of text (PRIMARY) > - switch to another application > - paste from PRIMARY > - paste from CLIPBOARD Works for me. The author of XTerm is quite reactive if you can explain the issue clearly, I am not surprised it was fixed. Regards, -- Nicolas George
xterm PRIMARY and CLIPBOARD selection [was: Re: Copy from Firefox and paste into Terminal with Vim]
On 07/02/2024 00:38, Nicolas George wrote:
Max Nikulin (12024-02-07):
Shift Ctrl C:
CtrlInsert is the standard counterpart to ShiftInsert.
It may be a convention for applications other than terminals, however I
am unsure what "standard" means for terminals. Konsole has "reverted"
bindings: [Shift+Insert] for CLIPBOARD and [Ctrl+Shift+Insert] for
PRIMARY. Unsure if it was so before appearance of Wayland (it did not
support PRIMARY at first). I have seen a (likely) KDE bug that paste
from PRIMARY by middle click is a security issue, so it should not be
supported.
Certainly, it is up to you if you wish to have [Ctrl+Insert] binding. I
am unaware of any conflicts with applications running in terminals.
exec-formatted("sh -c 'xsel --output --primary | \
exec xsel --input --clipboard'", PRIMARY)\n\
copy-selection(CLIPBOARD)
… is simpler.
Thanks, it seems, it works in bookworm. Several years ago xterm did not
support ownership of independent CLIPBOARD and PRIMARY simultaneously.
It was a workaround for the following scenario:
- select some text
- copy it to CLIPBOARD
- select another fragment of text (PRIMARY)
- switch to another application
- paste from PRIMARY
- paste from CLIPBOARD
I have the following note
! Allow both primary selection and clipboard copy-paste
! Ctrl+Shift+V, Ctrl+Shift+Insert, Ctrl+Shift+C similar to gnome-terminal
! Should work out of the box:
! Shift Insert:insert-selection(SELECT, CUT_BUFFER0)
! Notice that copy-selection(CLIPBOARD) binds PRIMARY and SELECTION, see
! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588785#108
! There is no point to use CUT_BUFFER1 as in xterm(1) "Custom Key Bindings"
! insert-selection(CLIPBOARD, CUT_BUFFER1)
Likely the related changes
https://invisible-island.net/xterm/xterm.log.html#xterm_336
Patch #336 - 2018/09/19
ensure that only one of PRIMARY and CLIPBOARD is owned by xterm
at a given time (Debian #901249).
https://invisible-island.net/xterm/xterm.log.html#xterm_338
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).
For me it is not easy to follow discussions of xterm bugs and to read
man page selections related to selection.
