Passive clipboard sync between selections

[ferki]

Currently when I'm making a new selection, it's not possible to right away paste it, but first it has to be either explicitly copied e.g. via a keyboard shortcut, or chosen as an entry via e.g. dmenu.

My understanding is that's because the primary selection is holding the currently selected text, but explicit copy/paste operations work from clipboard.

Since I only make a selection if I want to paste it later (usually right away), I already adopted a workflow long time ago to skip the explicit copy step (which would update the content of clipboard with the current selection, essentially syncing it with the content of primary at that moment). I believe the driving force behind this for me was a function named "sync selection contents" or similar in Parcellite.

Locally, I have a small patch for this kind of functionality, which just forcibly updates clipboard with current selection. I've recently also put this call behind a CM_SYNC_SELECTIONS environment variable to make it opt-in.

I would like to send a PR soon about it (have to rebase/squash/etc. first), but I'm opening this issue to have a place early for discussion about the feature.

[advilm]

I've just been doing && xdotool key shift+Insert in order to paste.

[ferki]

If I understand correctly, shift+Insert pastes the selection directly. It sounds like an interesting approach, thanks! :+1:

Judging by a quick search around, it might not be universally supported on all OS/DE/terminal/etc. combinations, but it might be good enough for my use case (have to test for some time). For others, I believe having on option to sync primary and clipboard would still be useful, though.

[advilm]

I use shift+Insert because it works in console and other apps I use while control+v doesn't work in most terminals and control+shift+v works in most terminals but doesn't work in some other places (like this textbox).

[ferki]

Shift+Insert doesn't seem to work for me in all situations. Highlighting text in browser, then pasting into terminal works, but not the other way around. Enabling CM_SYNC_SELECTIONS=1 with the patch on #126 makes it work for me in both directions. I'll try to see if I can solve this by patching the terminal instead, perhaps that's easier.

[OJFord]

I was going to make the same request; I already use xdotool key --clearmodifiers Shift+Insert on a keyboard shortcut to paste, but as ferki says that doesn't work for example pasting into the browser from the terminal, because Shift+Insert pasted from the clipboard buffer, not primary; so applications that use both (basically, GUIs) will either paste nothing, or whatever was previously (and is still) on the clipboard.

(That can be verified by making a selection in the terminal, and then viewing xclip -selection primary -o & xclip -selection clipboard -o.)

So the behaviour I would like from clipmenu is that primary/clipboard sync happens not only on clipmenu & choice made, but also automatically, when clipnotify notifies.

[OJFord]

I think @cdown understands this from the title change made, but just in case and to be clear - I don't believe this needs to be a 'passive' (to me implying its ongoing or periodic) sync 'between selections', just to sync when a selection (an X selection, not a clipmenu menu selection) is made, i.e. when clipnotify returns.

I'd be happy to work up a PR.

I don't understand this:

        if (( CM_OWN_CLIPBOARD )) && [[ $selection == clipboard ]]; then
            # Only clipboard, since apps like urxvt will unhilight for PRIMARY
            _xsel -o --clipboard | _xsel -i --clipboard
        fi

(Put what's on the clipboard... on the clipboard?)

But roughly I think something like:

        if [[ $selection == primary ]]; then
            _xsel -o --primary | _xsel -i --clipboard
        fi

in ~the same place is all that's needed. (But maybe you want this behind an env var toggle, etc.)

[cdown]

(Put what's on the clipboard... on the clipboard?)

X doesn't have a clipboard itself. Instead, it provides an API for applications to serve selection requests on demand. If they go away, so does the clipboard content.

The code under CM_OWN_CLIPBOARD make sure that we (as xsel) take ownership of the content on the CLIPBOARD selection -- it's not meaningless.

The reason we don't do anything with PRIMARY is clearly documented in the comment.

[OJFord]

X doesn't have a clipboard itself. Instead, it provides an API for applications to serve selection requests on demand. If they go away, so does the clipboard content.

Ah that makes sense - thanks.

The reason we don't do anything with PRIMARY is clearly documented in the comment.

Probably it's just that I don't know enough about this, but it's not clear to me. I use alacritty rather than urxvt, but there:

~>sleep 3 ; xsel --primary -o | xsel --clipboard -i
[here I selected something from the xsel usage printed above]
~>xsel --primary -o
cify fi
\ No newline at end of selection
~>xsel --clipboard -o
cify fi
\ No newline at end of selection
~>

and after the -o | -i returned, 'cify fi' was still highlighted. (The sleep is because it unhighlights on any keystroke.)

Contrast to copy-pasting your quotes above, for which I had to make the selection, hit clipmenu shortcut, choose the top item, hit (via other shortcut) Shift+Insert.

I'd like to only invoke clipmenu when I want a selection other than the most recent to be ready to insert.

[ferki]

@OJFord: there's already PR #126 from me with practically the same logic you proposed above + a config options to make this behavior opt-in for those who need it. I believe you might be interested to give that a try.

I'm happy to rebase my patch on top of current master if needed. Feedback on the PR is welcome!

[OJFord]

@ferki So there is, sorry :+1:

[ferki]

@ferki So there is, sorry

Oh, no worries, I hope the PR is useful for you too! :)