Option to copy into "main" clipboard on selection #288

Closed
opened 9 months ago by sv · 26 comments
sv commented 9 months ago

Currently, selected text if copied into the Primary Selection only. Some users might use regular Clipboard 99% of the time and not even know that former exists.

It would be useful to have an option that makes foot copy selected text to the regular clipboard in addition (instead of?) Primary Selection.

Currently, selected text if copied into the Primary Selection only. Some users might use regular Clipboard 99% of the time and not even know that former exists. It would be useful to have an option that makes `foot` copy selected text to the regular clipboard in addition (instead of?) Primary Selection.

I noticed that some apps like yeb just use the normal clipboard and I can't paste anything from it in foot.

I noticed that some apps like yeb just use the normal clipboard and I can't paste anything from it in foot.
Owner

It would be useful to have an option that makes foot copy selected text to the regular clipboard in addition (instead of?) Primary Selection.

@sv I can see that some would find this useful, and given that the rest of the clipboard handling (i.e. key bindings) are configurable, I guess it does make sense to make this configurable too.

However, I don't buy the reasoning. If we make this configurable in foot, the default would still be the primary selection. I.e. users would still have learn about its existance.

I noticed that some apps like yeb just use the normal clipboard and I can't paste anything from it in foot.

@FoundOne I'm afraid I haven't heard of "yeb" before. And a search didn't really turn up anything useful.

That said, foot can still access the regular clipboard: ctrl+shift+c copies the currently selected text to the regular clipboard, and ctrl+shift+v pastes from it (and like all other key bindings in foot, you can remap them to whatever you want).

If that doesn't work, then there's a problem. But it likely has nothing to do with this issue. Can you open up a new issue for that?

> It would be useful to have an option that makes foot copy selected text to the regular clipboard in addition (instead of?) Primary Selection. @sv I can see that some would find this useful, and given that the rest of the clipboard handling (i.e. key bindings) are configurable, I guess it does make sense to make this configurable too. However, I don't buy the _reasoning_. **If** we make this configurable in foot, the default would _still_ be the **primary selection**. I.e. users would still have learn about its existance. > I noticed that some apps like yeb just use the normal clipboard and I can't paste anything from it in foot. @FoundOne I'm afraid I haven't heard of "yeb" before. And a search didn't really turn up anything useful. That said, foot can still access the regular clipboard: <kbd>ctrl</kbd>+<kbd>shift</kbd>+<kbd>c</kbd> copies the currently selected text to the regular clipboard, and <kbd>ctrl</kbd>+<kbd>shift</kbd>+<kbd>v</kbd> pastes from it (and like all other key bindings in foot, you can remap them to whatever you want). If _that_ doesn't work, then there's a problem. But it likely has nothing to do with this issue. Can you open up a new issue for that?
dnkl added the
enhancement
easy
labels 9 months ago

Wouldn't it be better to redirect all primary selection for all applications to the main clipboard? If so, wl-clipboard could handle this. Or do you only want foot to have this behavior?

Currently, selected text if copied into the Primary Selection only. Some users might use regular Clipboard 99% of the time and not even know that former exists.

What other applications copy to clipboard on primary selection? I think a lot of foot users use primary selection, at least I do. I like to use it as a "temporary clipboard" since I save the main clipboard to disk.

Wouldn't it be better to redirect all primary selection for all applications to the main clipboard? If so, wl-clipboard could handle this. Or do you only want foot to have this behavior? >Currently, selected text if copied into the Primary Selection only. Some users might use regular Clipboard 99% of the time and not even know that former exists. What other applications copy to clipboard on primary selection? I think a lot of foot users use primary selection, at least I do. I like to use it as a "temporary clipboard" since I save the main clipboard to disk.
sv commented 9 months ago
Poster

the default would still be the primary selection

Absolutely. I wasn't proposing to change the default, only to give users an option they can configure.

What other applications copy to clipboard on selection?

Err... Plenty? Vim is often setup to "yank" into "+, some of the XTerm users add XTerm*selectToClipboard: true, etc.

> the default would still be the primary selection Absolutely. I wasn't proposing to change the default, only to give users an option they can configure. > What other applications copy to clipboard on selection? Err... Plenty? Vim is often setup to "yank" into `"+`, some of the XTerm users add `XTerm*selectToClipboard: true`, etc.

Err... Plenty? Vim is often setup to "yank" into "+, etc.

I mean to say what other applications copy to (regular) clipboard on primary selection (Sorry didn't proofread). Specifically, any other terminal emulators that do this.

Primary and regular selection are two different streams. Vim uses "* for primary selection, while "+ is for regular selection.

>Err... Plenty? Vim is often setup to "yank" into "+, etc. I mean to say what other applications copy to (regular) clipboard on *primary selection* (Sorry didn't proofread). Specifically, any other terminal emulators that do this. Primary and regular selection are two different streams. Vim uses `"*` for primary selection, while `"+` is for regular selection.
sv commented 9 months ago
Poster

OK, let's break it down. How about this:

  1. Default behaviour stays as it is, nothing changes.
  2. Users receive an option:
    copy_selected=clipboard,primary
    
  3. If variable is declared, foot copies selection to the approriate destinations.

Sounds reasonable?

OK, let's break it down. How about this: 1. Default behaviour stays as it is, nothing changes. 2. Users receive an option: ```ini copy_selected=clipboard,primary ``` 3. If variable is declared, `foot` copies selection to the approriate destinations. Sounds reasonable?
Owner

What other applications copy to clipboard on selection?

@JorwLNKwpH Alacritty has save_to_clipboard that appears to enable this behavior.

some of the XTerm users add XTerm*selectToClipboard: true

And apparently XTerm does too.

Those are the only applications I know of that does this. But then this is a feature I don't use myself, and I haven't really been looking for it.

If there are other GUI applications that (can) copy the mouse selection to the clipboard, I'd like to know.

I think a lot of wlroots users use primary selection, at least I do

Having one clipboard for mouse selections, and another for keyboard-copied text isn't terminal specific, Wayland specific, or new, in any way.

Virtually all X applications work like this.

Though I guess it is possible to have been using Linux for a while without having noticed this.

When Wayland was new, it lacked a protocol for the primary selection. Thus, for a while, there was no support in any Wayland compositor. But I think all compositors have caught up now, and do support it.

@sv I think it will be ok to add an option like you described. Though I would also add both as a valid value.

I just don't want the reason to be "people don't know about the primary selection". But given there is prior art, I think we can justify adding it to foot too.

> What other applications copy to clipboard on selection? @JorwLNKwpH Alacritty has `save_to_clipboard` that appears to enable this behavior. > some of the XTerm users add XTerm\*selectToClipboard: true And apparently XTerm does too. Those are the only applications I know of that does this. But then this is a feature I don't use myself, and I haven't really been looking for it. If there are other GUI applications that (can) copy the mouse selection to the clipboard, I'd like to know. > I think a lot of wlroots users use primary selection, at least I do Having one clipboard for mouse selections, and another for keyboard-copied text isn't terminal specific, Wayland specific, or new, in any way. Virtually all X applications work like this. Though I guess it is possible to have been using Linux for a while without having noticed this. When Wayland was new, it lacked a protocol for the primary selection. Thus, for a while, there was no support in any Wayland compositor. But I think all compositors have caught up now, and do support it. @sv I think it will be ok to add an option like you described. Though I would also add `both` as a valid value. I just don't want the _reason_ to be "people don't know about the primary selection". But given there **is** prior art, I think we _can_ justify adding it to foot too.

Just to clarify, I'm not opposed to the feature; I just question the value of adding more options to foot when the desired behavior can be achieved without a foot-specific option.

Wouldn't it be better to redirect all primary selection for all applications to the main clipboard? If so, wl-clipboard could handle this. Or do you only want foot to have this behavior?

For example, I tested wl-paste -pw wl-copy -t text/plain and this seems to accomplish the desired effect.

And this works for all applications rather than being limited to foot.

@dnkl:

I don't know why I said "wlroots users" when I meant to say "foot users". (Freudian slip? Isn't foot the standard terminal emulator for wlroots users anyways :P)

Secondly, the only useable wayland compositors for me are the ones with server-side decorations and primary selection ;).

Just to clarify, I'm not opposed to the feature; I just question the value of adding more options to foot when the desired behavior can be achieved without a foot-specific option. >Wouldn't it be better to redirect all primary selection for all applications to the main clipboard? If so, wl-clipboard could handle this. Or do you only want foot to have this behavior? For example, I tested `wl-paste -pw wl-copy -t text/plain` and this seems to accomplish the desired effect. And this works for *all* applications rather than being limited to foot. @dnkl: I don't know why I said "wlroots users" when I meant to say "foot users". (Freudian slip? Isn't foot the standard terminal emulator for wlroots users anyways :P) Secondly, the only useable wayland compositors for me are the ones with server-side decorations and primary selection ;).
Owner

For example, I tested wl-paste -pw wl-copy -t text/plain and this seems to accomplish the desired effect.

@JorwLNKwpH but you still need to bind this to a key? Or am I missing something?

> For example, I tested wl-paste -pw wl-copy -t text/plain and this seems to accomplish the desired effect. @JorwLNKwpH but you still need to bind this to a key? Or am I missing something?

No? Did you try it out? Just run it when your compositor is up (exec wl-paste -pw wl-copy -t text/plain in sway)

No? Did you try it out? Just run it when your compositor is up (`exec wl-paste -pw wl-copy -t text/plain` in sway)
Owner

No? Did you try it out?

No, but I (tried to) read the man page. I obviously failed 😂

I agree. This appears to be a valid alternative. Unless there's a use case for enabling 'select-to-clipboard' in just a few select applications instead of globally. @sv ?

> No? Did you try it out? No, but I (tried to) read the man page. I obviously failed 😂 I agree. This appears to be a valid alternative. Unless there's a use case for enabling 'select-to-clipboard' in just a few select applications instead of globally. @sv ?
sv commented 9 months ago
Poster

@sv I think it will be ok to add an option like you described. Though I would also add both as a valid value.

Totally up to you. This proposal is about giving users a choice after all.

I agree. This appears to be a valid alternative. Unless there's a use case for enabling 'select-to-clipboard' in just a few select applications instead of globally. @sv ?

While the solution by @JorwLNKwpH is certainly creative, there are several issues with it:

  1. It doesn't work with nVim: text selected with Shift is copied to Primary, but not to the clipboard.
  2. It implies having separate wl-copy as well as wl-paste process constantly running in background and polling Wayland / temp file / cleanup.
  3. It opens doors to all the interesting security implications as wl-copy isn't restricted to foot.
> @sv I think it will be ok to add an option like you described. Though I would also add both as a valid value. Totally up to you. This proposal is about giving users a choice after all. > I agree. This appears to be a valid alternative. Unless there's a use case for enabling 'select-to-clipboard' in just a few select applications instead of globally. @sv ? While the solution by @JorwLNKwpH is certainly creative, there are several issues with it: 1. It doesn't work with nVim: text selected with <kbd>Shift</kbd> is copied to Primary, but not to the clipboard. 2. It implies having separate `wl-copy` as well as `wl-paste` process constantly running in background and polling Wayland / temp file / cleanup. 3. It opens doors to all the interesting security implications as `wl-copy` isn't restricted to `foot`.
  1. I can't reproduce. Could you share your config and steps to reproduce somewhere?
  2. There is no polling involved thanks to the data-control protocol.
  3. I don't really get this argument since wl-clipboard is using the Wayland compositor features that are available to it. If this is really the case, then any arbitrary client can already cause harm by using these interfaces.
1. I can't reproduce. Could you share your config and steps to reproduce somewhere? 2. There is no polling involved thanks to the data-control protocol. 3. I don't really get this argument since `wl-clipboard` is using the Wayland compositor features that are available to it. If this is really the case, then any arbitrary client can already cause harm by using these interfaces.
sv commented 9 months ago
Poster

I can't reproduce. Could you share your config and steps to reproduce somewhere?

Config

https://github.com/savchenko/debian/blob/bullseye/roles/dotfiles/files/vimrc

Steps to reproduce
  1. nVim and foot from Debian Bullseye:
    $ nvim --version
    NVIM v0.4.4
    Build type: Release
    LuaJIT 2.1.0-beta3
    $ foot --version
    foot version: 1.6.2 +ime
    
  2. Config from the above.
  3. Select text with Shift+LMB.

There is no polling involved thanks to the data-control protocol.

m? aa4633b894/src/wl-copy.c (L197-L294)

Shall we count spawning of wl-copy each time Primary changes?..

I don't really get this argument since wl-clipboard is using the Wayland compositor features that are available to it.

There is no default action for "each time Primary changes". Adding the proposed line to Sway config introduces such behaviour and might allow resource exhaustion by continuously passing large object to the Primary, etc.

> I can't reproduce. Could you share your config and steps to reproduce somewhere? ##### Config https://github.com/savchenko/debian/blob/bullseye/roles/dotfiles/files/vimrc ##### Steps to reproduce 1. nVim and `foot` from Debian Bullseye: ```sh $ nvim --version NVIM v0.4.4 Build type: Release LuaJIT 2.1.0-beta3 $ foot --version foot version: 1.6.2 +ime ``` 2. Config from the above. 3. Select text with Shift+LMB. > There is no polling involved thanks to the data-control protocol. m? https://github.com/bugaevc/wl-clipboard/blob/aa4633b894c3c5ae6053026529ec9288566060a6/src/wl-copy.c#L197-L294 Shall we count spawning of `wl-copy` each time Primary changes?.. > I don't really get this argument since wl-clipboard is using the Wayland compositor features that are available to it. There is no default action for "each time Primary changes". Adding the proposed line to Sway config introduces such behaviour and might allow resource exhaustion by continuously passing large object to the Primary, etc.
Owner

@sv @JorwLNKwpH sometimes seeing the implementation can help with the decision making. So I implemented a POC in #302.

As can be seen, the implementation is really small, which speaks in its favour.

@sv @JorwLNKwpH sometimes seeing the implementation can help with the decision making. So I implemented a POC in https://codeberg.org/dnkl/foot/pulls/302. As can be seen, the implementation is really small, which speaks in its favour.

Well since @dnkl wrote the patch might as well merge it. :)

About point 3 though, isn't that a bug with the compositor? (and I'm not sure it will happen in normal use)

Well since @dnkl wrote the patch might as well merge it. :) About point 3 though, isn't that a bug with the compositor? (and I'm not sure it will happen in normal use)
dnkl closed this issue 9 months ago
dnkl referenced this issue from a commit 9 months ago
sv commented 9 months ago
Poster

Seems like this wasn't merged in v1.6.3 (?)
Just updated on Debian and adding selection-target=both returns an error:

error: /home/sv/.config/foot/foot.ini:18: [default]: selection-target: invalid key

foot version: 1.6.3 +ime

Seems like this wasn't merged in v1.6.3 (?) Just updated on Debian and adding `selection-target=both` returns an error: ``` error: /home/sv/.config/foot/foot.ini:18: [default]: selection-target: invalid key ``` foot version: 1.6.3 +ime
Owner

@sv right, it was not. Usually only bug fixes go into patch releases.

In this case, it would probably have been fine to include the patch, but I'll admit it just didn't cross my mind...

@sv right, it was not. Usually only bug fixes go into patch releases. In this case, it would probably have been fine to include the patch, but I'll admit it just didn't cross my mind...
sv commented 9 months ago
Poster

All good! Fingers crossed this will make it in whatever version goes into Debian Bullseye.

All good! Fingers crossed this will make it in whatever version goes into Debian Bullseye.
Owner

@sv fwiw, the patch has been backported to the 1.6.x release branch. Not released yet, but I do expect one within the next days/week.

@sv fwiw, the patch has been backported to the 1.6.x release branch. Not released yet, but I do expect one within the next days/week.
Collaborator

The soft freeze date for Debian Bullseye is today, so it seems likely it won't make it in. Although I don't know much about Debian, so I could be wrong.

The [soft freeze](https://release.debian.org/bullseye/freeze_policy.html) date for Debian Bullseye is today, so it seems likely it won't make it in. Although I don't know much about Debian, so I could be wrong.
sv commented 8 months ago
Poster

Well, it still can make it. So far, mr.Schacht has been packaging versions with the speed of light. Here is the excerpt from the official policy:

Starting 2021-02-12, only small, targeted fixes are appropriate for bullseye. We want maintainers to focus on small, targeted fixes. This is mainly at the maintainers discretion, there will be no hard rule that will be enforced.

It appears that before "Full Freeze" it is up to Birger if a new version is considered to be safe enough.

Well, it still can make it. So far, mr.Schacht has been packaging versions with the speed of light. Here is the excerpt from the official policy: > Starting 2021-02-12, only small, targeted fixes are appropriate for bullseye. We want maintainers to focus on small, targeted fixes. This is mainly at the maintainers discretion, there will be no hard rule that will be enforced. It appears that before "Full Freeze" it is up to Birger if a new version is considered to be safe enough.
Owner

Current CHANGELOG for 1.6.4.

I will not release until #353 has been merged.

1.6.4 is likely the last patch release for 1.6.x.

Current [CHANGELOG](https://codeberg.org/dnkl/foot/src/commit/caede905447164acb2018b2f411b6aa749da9736/CHANGELOG.md#user-content-1-6-4) for 1.6.4. I will not release until https://codeberg.org/dnkl/foot/pulls/353 has been merged. 1.6.4 is likely the last patch release for 1.6.x.
Owner
@sv https://codeberg.org/dnkl/foot/releases/tag/1.6.4
sv commented 8 months ago
Poster

That was remarkably fast! Just sent an e-mail to Birger.

Thank you.

That was remarkably fast! Just sent an e-mail to Birger. Thank you.
sv commented 8 months ago
Poster

Birger's response, posting with his permission:

I've just uploaded foot 1.6.4 to unstable. It will take 10 days to transition to testing, given that the soft freeze [0] started yesterday.

Birger's response, posting with his permission: > I've just uploaded foot 1.6.4 to unstable. It will take 10 days to transition to testing, given that the soft freeze [0] started yesterday.
Sign in to join this conversation.
No Milestone
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.