Copy/Paste from tmux to Windows

[Michael Grant]

I didn't want to hijack Eric's other thread which is clearly X based so starting a new thread here.  

I'm using Windows.  I ssh into my linux servers with KiTTY and run tmux on the linux server.  No, I do not want to install an X server on windows, thanks very much,

KiTTY (a windows program which is a fork of PuTTY) not to be confused with kitty, a terminal emulator that runs under linux.  It seems the linux kitty supports OSC52 by the way.

I don't think KiTTY supports OSC52 (yet), at least, I've never gotten it to work.  But it does support taking the output to the printer and putting that into the local clipboard: http://www.9bis.net/kitty/index.html#!pages/StdoutToClipboard.md

Try 1, I added this to my .tmux.conf:

bind -Tcopy-mode MouseDragEnd1Pane send -X copy-pipe-and-cancel '~/bin/wcl'

Unfortunately, tmux filters out the escape characters, the raw output is not getting to KiTTY.  

I've tried pipping something to wcl outside tmux (as in, before starting tmux) and it does work, i can paste on the windows side. 

First thought, is there some tmux command I can run which will echo something back to the raw terminal (KiTTY in my case)?  

Second thought was maybe I could craft an Ms entry for a terminfo override.  This is what I tried:

Try 2, added this to my .tmux.conf instead:

set -as terminal-overrides ',*-256color:Ms=\E[5i;%p2%s;\E[4i'

Restarted tmux (killed the server and restarted it).  And it's tantelizingly close.  I get base64 text on the windows side!

One difference between OSC52 and this KiTTY hack is that OSC52 expects the string to be base64 encoded whereas printing to the printer doesn't expect that.  Is there some param that sends the raw text, not base64 encoded?

Second, with this method, how can set the behavior to do the copy when I release the mouse button? (MouseDragEnd1Pane)

Michael Grant

[Nicholas Marriott]

Hi

No, it needs to be encoded somehow in case the copied text contains control characters. If you are sure it won't you could modify tmux to skip the base64 (look for b64_ntop in tty_set_selection)

You will never get control characters by copying using copy mode except for newline, so I don't know what you mean when you say "tmux filters out the escape characters".

You can send to the terminal directly using the passthrough escape sequence (see the FAQ).

--
You received this message because you are subscribed to the Google Groups "tmux-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tmux-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/70847815-9ce9-4940-8815-1518690d52ban%40googlegroups.com.

[Michael Grant]

Right, you're correct, the copy-buffer will never get control characters by copying using copy mode except newlines and multibyte unicode.

Can you (or someone) please explain those params in the tmux Ms terminfo entry?  What's %p1%s?  The %p2%s appears to be the base64 encoded paste buffer.  Maybe one could add a %p3%s which is the raw, not base64 that could be used for this purpose?  To be honest, this method would be cleaner and simpler than my script below.

When I couldn't get this working earlier, I thought tmux was filtering the escape codes but the problem wasn't passthrough, it was that I wasn't sending the output to the correct tty.

Here is the current wcl script:

# start send to ansi printer
echo -ne '\e[5i' >$SSH_TTY

# send stdin to the outer terminal
cat >$SSH_TTY

# end ansi printer output
echo -ne '\e[4i' >$SSH_TTY

and in my .tmux.conf I have this line:

bind -Tcopy-mode MouseDragEnd1Pane send -X copy-pipe-and-cancel '~/bin/wcl'

and I set the ansi printer in KiTTY to print to the clipboard as per http://www.9bis.net/kitty/index.html#!pages/StdoutToClipboard.md

and now, when I select text in a tmux window with a shell, it magically is available in my Windows clipboard.

If I middle click in tmux, it's pasted back into the shell.  Ahh, so nice!  Used it already multiple times to write this post!  

This works but I do have a problem with unicode characters that are encoded as multiple bytes.  When there's a unicode code-point that would encode to multiple characters in utf-8 on the sceen in tmux that I copy into the copy-buffer, then paste it into Windows, I get the multi bytes instead of the single character.  For example, if i have '€100' in tmux, select it to copy it, then paste it back into windows, i get '€100'.

I don't know where the problem lies here.  The editor window (notepad++) on windows certainly supports unicode.  The linux side certainly does too.  Something along the way is re-encoding each of the characters in the multi-byte sequence as a single unicode codepoint and then sending a multi-byte character for each of those characters.  It could be a manifestation of this printer to clipboard hack and if we can get the terminfo param to do raw output, maybe that would fix this?  This might be a KiTTY issue.  I am not sure and unsure how to debug this at the moment.

By the way, there are some typos on the github documentation page on passthrough which I will try to find the time to do a PR.  In the end, I didn't need to use passthrough though I did get it working and it does not help the unicode problem.

So the first thing I tried was to copy something from the shell and then edit a file in the same tmux window with vi and paste it into the file.  When I run an editor such as vi or emacs, tmux seems to switch to an alternate terminal screen within the terminal.  By this, I mean, when I exit vi, instead of seeing the bottom part of the vi session still on my screen, the screen is returned to the way it was before entering the editor.  The ansi term for this may be 'anternate screen'.  Terminfo seems to calls this 'smcup'.  There seems to be a separate paste buffer associated with the middle click when I'm in the alternete screen.  Or maybe the editor is controlling this button?  I'm not wholey sure.  Whatever it is, I can't find a way to paste the tmux clipboard into the editor.  This is reproducible without any of the copy-mode settings above and has nothing to do with Windows, and I don't think it has anything to do with KiTTY either, KiTTY seems to be sending middle click to tmux regardless of whether I'm in vi or at the shell prompt.  

Is there some way to paste from the copy-buffer into an editor such as vi or emacs, both in the same tmux?  (Windows not involved here).

[Nicholas Marriott]

%pX means push parameter X. We can't add unused parameters because newer ncurses will validate the number of parameters. Anyway, sending raw output won't work as a general solution because the clipboard may have characters that cannot be sent like \033.

My guess for UTF-8 would be that either Windows or kitty doesn't know about UTF-8 in this output and is treating it as an 8-bit encoding. If you can't configure this in the terminal you could maybe pass the text through iconv to make it the right encoding so at least some characters would work.

To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/dcc1541b-8edd-4e8f-9565-e36978f5e3fcn%40googlegroups.com.

[Nicholas Marriott]

I assume you are using the terminal to middle click paste since tmux does not do this by default, in which case it has probably disabled the mouse when the application has requested it. It seems unlikely to be alternate screen since tmux will enable that on attach and the terminal doesn't know what individual panes inside tmux are doing. Most terminals have a bypass key (sometimes shift) to ignore application mouse mode for an individual mouse event, or you could turn the mouse off in the editor so it doesn't enter application mouse mode at all.

Or the other option is to turn on mouse mode in tmux and bind the middle button to paste instead, in which case you can control whether it cares about application mouse mode or not in the key binding.

On Thu, 8 Jun 2023, 00:17 Michael Grant, <michae...@gmail.com> wrote:

To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/dcc1541b-8edd-4e8f-9565-e36978f5e3fcn%40googlegroups.com.

[Michael Grant]

>  We can't add unused parameters because newer ncurses will validate the number of parameters. 

I see.  

>   the clipboard may have characters that cannot be sent like \033.

Not exactly true, I can paste the ESC character into Notepad++ just fine, it shows up like `[esc]`.  Similarrly for control characters.  I verified this in one of my many tests yesterday.

I tried iconv today as suggested and couldn't find an encoding that pasted cleanly.  I tried converting utf-8 to utf-16 and a few others but nothing helped.  It looks like utf-8 to me.  Like I said, it seems like something is encoding each byte of a multi-byte encoding, so there's probably nothing i'm going to be able to do here, the damage happens further downstream.  This is not a tmux issue, it happens even outside tmux.  I've opened an issue in the KiTTY github repo on this.

Real OSC-52 support seems to be needed in KiTTY.  

How would one do the reverse?  How would one get data into tmux's copy-buffer so that middle-click pasted from the Windows clipboard back to tmux?  I have mouse mode enabled and on and I was using the middle click on the mouse.  It pastes what's in tmux's copy buffer into tmux within tmux.  I think I have the middle button bound to paste as you mention below, I didn't do anything special in my .tmux.conf to do this, seems like the default.

[Nicholas Marriott]

> Not exactly true, I can paste the ESC character into Notepad++ just fine, it shows up like `[esc]`.  Similarrly for control characters.  I verified this in one of my many tests yesterday.

That has nothing to do with it. How would the terminal know the difference between a clipboard containing \033\\ and the intended terminator?

> I think I have the middle button bound to paste as you mention below,

What is it bound to? Check with list-keys.

To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/9db74581-2cff-4403-8eb8-6646ccba0bc0n%40googlegroups.com.

[Nicholas Marriott]

Ah, I checked in the wrong place, it is bound by default:

$ tmux lsk MouseDown2Pane
bind-key -T root MouseDown2Pane select-pane -t = \; if-shell -F "#{||:#{pane_in_mode},#{mouse_any_flag}}" { send-keys -M } { paste-buffer -p }

If you remove the mouse_any_flag check it will not care if the application wants the mouse. So just change it to -F "#{pane_in_mode}".

[Michael Grant]

% tmux list-keys | grep MouseDown2

bind-key    -T root         MouseDown2Pane       select-pane -t = \; if-shell -F "#{||:#{pane_in_mode},#{mouse_any_flag}}" { send-keys -M } { paste-buffer -p }

I didn't bind that, that is the default for me.

[Michael Grant]

Adding this to my .tmux.conf as you suggest did seem to help, thanks!

bind-key -T root MouseDown2Pane select-pane -t = \; if-shell -F "#{pane_in_mode}" { send-keys -M } { paste-buffer -p }

[Michael Grant]

I'm trying to wrap my head around the other direction, from windows clipboard to tmux's copy-buffer.  Is that even possible?  How would one even do that?  As far as I know OSC-52 is only one direction.

[Nicholas Marriott]

If you had OSC 52 working you can use refresh-client -l (lowercase L) to read it from the terminal.

Without OSC 52 you will need to send it to the remote host out of band and load it with tmux load-buffer

To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/31f8997a-fd50-4e5d-895b-79be1f7e2bd1n%40googlegroups.com.

[Michael Grant]

From the tmux man page:

             -l requests the clipboard from the client using the xterm(1) escape sequence.  If Ar target-pane is
             given, the clipboard is sent (in encoded form), otherwise it is stored in a new paste buffer.

Does refresh-client -l also work with OSC-52?  The man page may need to be updating.

How would you use this?  Would you bind MouseDown2Pane to first refresh-client to sync the buffer and then paste?

[Nicholas Marriott]

You won't be able to do that without also having a delay (eg "run -d0.5") otherwise it is likely the clipboard will not have been received by the time the paste command runs.

To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/6f993238-b0af-4849-9194-5205cec8c10cn%40googlegroups.com.