Clipetty not sending cuts to clipboard under local tmux

[jpe90]

Clipetty works for me when I use it outside tmux, or under SSH and tmux, but not under tmux for a local system.

This occurs regardless of whether emacs is run as a daemon or regularly, in all terminals I've tried (kitty, ST, and alacritty) on Linux.

I've tried debugging in the failing case, where I'm using tmux locally.

In this call to clipetty-emit with the encoded string that it want to cut, which in the case is the text defun, (clipetty--dcs-wrap string tmux term ssh-tty) evaluates to the following:

and (clipetty-tty ssh-tty tmux) evaluates to "/dev/tty".

Not sure whether that's behaving as expected, but my clipboard doesn't end up receiving the cut.

When I run without tmux, (clipetty--dcs-wrap string tmux term ssh-tty) evaluates to "^[]52;c;ZGVmdW4=^G" and the clipboard does receive the cut.

[tyama711]

@jpe90
What version of Tmux are you using?
Starting with Tmux 3.3, Escape Sequence Passthrough is optional.
You can enable it by adding the following to your .tmux.conf.

set -g allow-passthrough on

[jpe90]

@tyama711
I'm using tmux 3.3a. I gave that setting a shot, and turned off all my existing settings to make sure there isn't a conflict, but it didn't seem to solve the issue.

I found using the xclip package alongside clipetty works was a workaround. I didn't realize that it's actually cross-platform and supports Wayland/Windows/MacOS/etc despite the name.

[SadSock]

I have encountered the same problem.

[vkz]

same problem with tmux 3.4 on Mac. Neither kitty nor iterm seem to work with or without

set -g allow-passthrough on

[vkz]

I just built tmux 3.2 from source and the problem remains, so I'm thinking it maybe clipetty to blame after all

[vkz]

For laughs I did ssh localhost then test clipetty inside tmux. As expected it works. But the most hilarious part is that from then on it works even without ssh i.e. with local tmux session. Until you kill terminal completely that is. You gotta loop at least once over ssh to get it to work again. I'm thinking that some environment thing gets triggered. If this gets maintainers any clues - great