Shift+Ins vs. Middle Mouse Button
Shift+Ins vs. Middle Mouse Button
Why is it, that some applications (namely Firefox and VSCode) seems to place the current selection into the buffer that is accessed with the middle Mouse Button and not the one accessed by Shift+ins, used anywhere else.
It seems usually selecting places the content into both buffers, but just not in platform ignorant builds…
This often breaks my work flow. Any idea on how to fix this?
nah
that's some age old struggle
idk how people still justify that clusterfuck, but it's that way since forever. I remember vividly how we were annoyed by such shit with some "cross platform" gui toolkits (or browsers) back when debian woody still was relevant.
This won't be solved in this decade. or the next.
It was solved in the not-too-distant past. Firefox had an option to turn of its willful misbehaviour until a few years ago when they decided to remove it.
There's a bug open for Firefox and you can change VSCode's behavior by putting this in your keybindings.json:
{ "key": "shift+insert", "command": "editor.action.selectionClipboardPaste", "when": "textInputFocus && !editorReadonly" }Not sure why either of them are messing with a "standard" shortcut...
If you want a more system-wide solution there are utilities that let you sync the PRIMARY (on selection) and CLIPBOARD (Ctrl+c) buffers mentioned in the Arch Wiki entry.Looked around some more - maybe it's because they're all GTK apps?
https://unix.stackexchange.com/questions/178070/why-does-shiftinsert-paste-from-clipboard-in-some-applications-and-primary-in-o
If you merge CLIPBOARD and PRIMARY, every time you select text, you'll wipe out the contents of CLIPBOARD. You won't be able to copy text, then do any work that involves selecting text, then paste.
Such stupidity, this drives me nuts
This is a problem that could only be fixed if Mozilla and whoever makes this "VSCode" thing cared about Linux. So it will not be fixed.
autocutsel -cutbuffer 0 -f -s PRIMARY autocutsel -f -s CLIPBOARD