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?

  • Cegorach@feddit.de
    11·
    1 year ago

    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.

  • feral_hedgehog@pawb.social
    8·
    1 year ago

    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.

  • tal@kbin.social
    3·
    1 year ago

    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.

  • ipsircEnglish
    1·
    1 year ago
    autocutsel -cutbuffer 0 -f -s PRIMARY
autocutsel -f -s CLIPBOARD