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?