Space-p and Space-R not working inside Tmux

[archseer]

Discussed in #8470

^{Originally posted by yusuphgammut October 6, 2023}
Hello.

I recently updated my operating system to macOs Ventura and since then the Space-p and Space-R keymaps are not working inside Tmux. However, Ctrl-v works as expected. Before that they worked ok. Any idea on how to address this?

Alacritty version: alacritty 0.13.0-dev (e35e5ad).
Tmux version: tmux 3.3a.
Helix version: helix 23.05 (072e1eae).

Outside Tmux, hx --health returns this:

Clipboard provider: pbpaste+pbcopy
System clipboard provider: pbpaste+pbcopy

Inside Tmux, hx --health returns this:

Clipboard provider: tmux
System clipboard provider: tmux

And tmux show -s set-clipboard returns this:

set-clipboard external

Seems to have started after #8182 because this prioritizes the tmux codepath over pbcopy/pbpaste. It seems to happen on iterm2 / default system terminal and the OSC 52 yank isn't forwarded to the system clipboard.

[archseer]

\cc @xJonathanLEI

Does macOS server still have pbcopy/pbpaste present? If not a simple fix would be inverting the if so that pb comes first.

I've been debugging with @teenjuna on Matrix to see if we can get load-buffer/save-buffer working with the system config but no success. If anyone has a working tmux config please share it here.

[archseer]

Might require set-clipboard on rather than external on tmux.

Another possibility is set-window-option -g allow-passthrough on

[teenjuna]

Might require set-clipboard on rather than external on tmux.

Another possibility is set-window-option -g allow-passthrough on

As I said on Matrix, this doesn't seem to help. With those options enabled:

alex@mac /tmp> echo test1 | pbcopy
alex@mac /tmp> pbpaste
test1
alex@mac /tmp> echo test2 | tmux load-buffer -w -
alex@mac /tmp> pbpaste
test1
alex@mac /tmp> tmux save-buffer -
test2

[xJonathanLEI]

Does macOS server still have pbcopy/pbpaste present?

I'm not sure if you're asking specifically about the discontinued macOS Server as I don't use it. I did mention about using a macOS "server" in #8182 but I actually meant just any macOS device with SSH server turned on. And yes on my Macbook these 2 binaries exist, so inverting the option would break tmux - which is why I put tmux first in #8182 in the first place.

Since this issue specifically mentions Space-p and Space-R but not Space-y, I'm assuming that this means yanking does work, which in turn means OSC 52 does work at least for yanking.

In fact, pasting does also work, but only for content you originally copied with tmux. This means that if you have 2 tmux windows running Helix, and you Space-y in one of them, Space-p would work as expected on another. This does not work for content copied outside of tmux though.

However, this is not specific to macOS. Using tmux on all systems has always been like this for me. I guess this is because tmux save-buffer - doesn't utilize OSC 52 but rather only dumps its internal buffer? In any case, I gotta say this is quite.. desirable to me. I always have a long running tmux working session on a server, and I SSH in from different devices. If it always uses OSC 52 and Space-p result changes just because I changed device it would be quite annoying to me.

[xJonathanLEI]

But if you have a different setup and always only use tmux locally, then I can see how this is a bit annoying (but again, I believe this is not specific to macOS - it used to not be an issue on macOS simply because tmux wasn't even supported before #8182). I think the ultimate solution here is to allow configuring clipboard providers (or do we already?) so that users can tailor the setup to their own usage.

But before that happens, I would vote for keeping it as-is, since the "using tmux locally" use case has a reasonable workaround: pressing the native paste shortcut; while the other side (i.e. "using tmux remotely") wouldn't have a solution if #8182 is reverted.

[teenjuna]

I can confirm that if I yank something inside helix, I can past it with tmux save-buffer - inside another tmux window, but not outside of tmux. And yes, this is workflow-breaking for my usecase.

since the "using tmux locally" use case has a reasonable workaround: pressing the native paste shortcut; while the other side

When pasting into helix: yes, it works. But copying from helix is not possible, and the only workaround I found is to use select-mode inside tmux, but that's limited to current scroll position and also copies line numbers. In other words, it's quite unusable.

I think the ultimate solution here is to allow configuring clipboard providers (or do we already?)

I think it would be great, but looks like it's not possible at the moment. I was going to just patch it locally and build from source, but failed due to some runtime directory mess (compiled with HELIX_DEFAULT_RUNTIME set to ~/.config/helix/runtime, but it still didn't detect TreeSitter grammars, although fetch and build worked properly. I will try that again later, but I hope that this issue can be solved in the very near future...

[xJonathanLEI]

I can past it with tmux save-buffer - inside another tmux window, but not outside of tmux.

Wait this doesn't sound right. It means your terminal emulator is not working with tmux. What terminal emulator are you using? iTerm 2?

[teenjuna]

Yes.

[xJonathanLEI]

Do you have this turned on? "Applications in terminal may access clipboard"

[teenjuna]

No I haven't! Thank you for this tip. It looks like yanking started to work! This makes it usable!

[teenjuna]

I guess this is why I had those lines as a workaround:

bind -T copy-mode-vi y send-keys -X copy-pipe-and-cancel "pbcopy"
bind -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "pbcopy"

[xJonathanLEI]

np happy to help :)

So now yanking should work perfectly. For pasting though, you will have to use different keys based on where you copied from.

[teenjuna]

Yeah, this is less than ideal, but still usable, and I'm happy to wait until clipboard provider can be set in config. I know that helix prefers to automatically decide things like this (as per comment from another maintainer on Matrix), but this issue proves that sometimes there are different use cases. Do you agree, @archseer?

[teenjuna]

@xJonathanLEI honest question: does unset tmux && hx have some hidden consequences for a local-only use case?

[archseer]

No I haven't! Thank you for this tip. It looks like yanking started to work! This makes it usable!

^ This is what I meant when I asked if you checked if OSC 52 forwarding was configured in iTerm2 settings

[archseer]

Allowing user config is something we should support but it wasn't needed until now since it's only necessary if there was a bug like this.

A solution for this specific case would be to always use the OSC 52 provider (it's currently only set as a fallback) in combination with any provider we detect. Then we wouldn't even need this tmux specific workaround with load-buffer

[teenjuna]

No I haven't! Thank you for this tip. It looks like yanking started to work! This makes it usable!

^ This is what I meant when I asked if you checked if OSC 52 forwarding was configured in iTerm2 settings

Yeah, my bad

[n8henrie]

Also just noticed this. hx 23.10, tmux on MacOS using Terminal.app.

Tmux is configured to use my MacOS clipboard with the copy-pipe-and-cancel commands from above, but copying to / from helix copies to / from the tmux clipboard and not my system clipboard.

Pasting from the system clipboard works fine with commandv (in insert mode), but copying is a little more tricky -- :run-shell-command tmux save-buffer - | pbcopy seems to do the trick.

[xJonathanLEI]

@n8henrie As noted in the thread, copying should work as long as your terminal can properly access clipboard via OSC 52, even if you're on tmux, as tmux itself would send a OSC 52 signal when yanking.

This comment from above shows how to enable OSC 52 for iTerm2. I don't personally use Terminal.app (in fact I use Asahi Linux most of the time now lol, it's awesome), so I'm not sure how to configure that. But once it's properly configured yanking should work for both tmux and system clipboard.

[xJonathanLEI]

Oh it looks like Terminal.app simply doesn't support OSC sequences. Someone event built a tool specifically to work around that.

I guess in this case the best solution is still to allow customizing clipboard provider. That doesn't seem to be a priority though, as I assume most users are on more advanced terminal emulators.

[n8henrie]

Thanks for your time @xJonathanLEI -- I'm pretty sure Terminal.app doesn't support OSC 52, I've investigated these issues in the past.

EDIT: you beat me to it

Also using Asahi (NixOS) a fair amount, dual booting :)

I might just try to figure out how to define a custom command in helix and use that as needed. Having helix copy and paste to tmux instead of the system clipboard isn't bad, just not what I'm used to!

[inianv]

@xJonathanLEI @teenjuna reading through this, I have a similar problem which I can't seem to resolve.

Basically I have helix (23.10) on a remote Linux machine running Ubuntu, connected through ssh & tmux in iTerm2. My .tmux.conf looks like below and I have checked the option in iTerm2 enabled as per the comment above

set -g default-terminal "tmux-256color"
set -g mouse on

set-clipboard on

On my tmux session, running hx --health shows below and I have both xclip and xsel installed on the machine.

Clipboard provider: tmux
System clipboard provider: tmux

The issue that I'm seeing is inability to read/write from system clipboard, i.e. copy/paste from inside the helix editor to outside iTerm2 (e.g. to a browser)

[thomasschafer]

Did anyone find a resolution for this? I'm using Tmux + Alacritty with Helix, and hx --health shows

Clipboard provider: tmux
System clipboard provider: tmux

Yanking to the system clipboard works fine, but not pasting from it, as others have discussed in this thread. The only solution I've found was the one mentioned here (i.e. unset TMUX). I'm wondering if we can just add an additional config setting that would bypass the check here?

[inianv]

@thomasschafer I ran out of options trying every single thing available out there. Basically I connect from my macos terminal (Alacritty) with OSC52 enabled for Copy and paste. I ssh into a Debian machine, where I operate over tmux. None of the said options work. Could you help with the config needed on both macos side and on the remote side?

[thomasschafer]

@thomasschafer I ran out of options trying every single thing available out there. Basically I connect from my macos terminal (Alacritty) with OSC52 enabled for Copy and paste. I ssh into a Debian machine, where I operate over tmux. None of the said options work. Could you help with the config needed on both macos side and on the remote side?

@inianv I'm afraid I don't know - I think your best option would be to build from source and fiddle with this function until you get something working, or even just have a look at that function without modification and see if there is a binary you might need to install

[thomasschafer]

After this PR was merged I've found that setting editor.clipboard-provider = "pasteboard" fixes this issue on macOS with Tmux. Should we just remove these two lines?