Support OSC52

[tdupes]

This would provide a way to copy text to the system clipboard even if you are using it through SSH without X forwarding. It's also a much cleaner design of delegating clipboard management to the emulator itself instead of helix having to handle different environments: X, Wayland, etc.

A solution to this potentially obsoletes #76

[pickfire]

Crossterm doesn't seemed to support that. Can you open this in upstream crates like https://github.com/crossterm-rs/crossterm and https://github.com/redox-os/termion which we might switch to later?

[archseer]

OSC52 doesn't fully solve #76 because it only does yanking, not pasting. Would be good to have support for though.

[kirawi]

Crossterm doesn't seemed to support that. Can you open this in upstream crates like https://github.com/crossterm-rs/crossterm and https://github.com/redox-os/termion which we might switch to later?

Termion isn't cross-platform, so I don't think we should switch to that.

[tdupes]

@archseer, I was taking the title of #76 too literally ("Yank to the clipboard").

@pickfire Is it necessary to rely on the crossterm for that? as far as I can tell it can implemented with a simple print statement. Unless I am missing something with how that would interfere/not be compatiable with crossterm

    print!("\x1B]52;c;{}\x07", base64::encode(&text_to_copy));

[pickfire]

@pickfire Is it necessary to rely on the crossterm for that? as far as I can tell it can implemented with a simple print statement. Unless I am missing something with how that would interfere/not be compatiable with crossterm

We could do that but then we need to add a layer on top of crossterm for or otherwise it breaks cross-platform compatibility, or maybe we just put compile time os flag, but it would be best if we can rely on crossterm or termwiz so only terminal that accept it gets it. Need to see what @archseer think.

[sudormrfbin]

FWIW #310 will land soon (it doesn't solve the SSH issue though).

[tdupes]

Have a solution hidden behind a feature flag on my fork at tdupes@f5cc704. Although it might make more sense to be a backup if the paste doesn't succeed as opposed to doing both the print and the paste

[theowenyoung]

Are there any updates about this?

[tdupes]

@theowenyoung Helix still does not support it directly but helix does support tmux as a clipboard provider and tmux has osc52 support so an osc52 sequence should be emitted when you copy if you are running helix in a tmux session.

[theowenyoung]

@tdupes Thanks! I tried on the remote server with tmux, but it seems still can not yank to the local system clipboard, do I need to do some config? remote tmux copy mode can copy to my local machine.

[tdupes]

You'll have to debug why the command provider for tmux isn't running. Could be something with the environment variables in your shell. Either another provider with higher precedent is overriding it or the proper vars for tmux aren't set. https://github.com/helix-editor/helix/blob/77ff8d355051ef567c7998b226e28ba436c2e230/helix-view/src/clipboard.rs On July 7, 2022 6:45:02 PM CDT, Owen ***@***.***> wrote: ***@***.*** Thanks! I tried on the remote server with tmux, but it seems still can not yank to the local system clipboard, do I need to do some config? remote tmux copy mode can copy to my local machine.

…

-- Reply to this email directly or view it on GitHub: #247 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[theowenyoung]

It seems that there aren't debug messages there. So I checked the conditions in my remote machine, I think it should go to the tmux branch, but nothing happened. I can be sure the TMUX-related variable is settled correctly. By the way, did you try it on a remote server with tmux? does it work fine?
.

 echo $TMUX && which tmux
/tmp/tmux-1000/default,55799,0
/usr/bin/tmux

[groves]

Had a crack at this in #3220

[the-mikedavis]

Closed by #3220