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.

On Thursday, 8 June 2023 at 10:19:23 UTC+1 Michael Grant wrote:

> 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 }
>
> On Thursday, 8 June 2023 at 10:12:44 UTC+1 Michael Grant wrote:
>
>> % 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.
>> On Thursday, 8 June 2023 at 10:06:16 UTC+1 nicholas...@gmail.com wrote:
>>
>>> > 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.
>>>
>>>
>>>
>>> On Thu, 8 Jun 2023 at 10:00, Michael Grant <michae...@gmail.com> wrote:
>>>
>>>> >  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.
>>>> On Thursday, 8 June 2023 at 05:12:40 UTC+1 nicholas...@gmail.com wrote:
>>>>
>>>>> %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.
>>>>>
>>>>>
>>>>> On Thu, 8 Jun 2023, 00:17 Michael Grant, <michae...@gmail.com> wrote:
>>>>>
>>>>>> 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).
>>>>>>
>>>>>> On Wednesday, 7 June 2023 at 14:14:09 UTC+1 nicholas...@gmail.com 
>>>>>> wrote:
>>>>>>
>>>>>>> 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).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 7 Jun 2023 at 13:22, Michael Grant <michae...@gmail.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> 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
>>>>>>>>  
>>>>>>>> <https://groups.google.com/d/msgid/tmux-users/70847815-9ce9-4940-8815-1518690d52ban%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>> .
>>>>>>>>
>>>>>>> -- 
>>>>>> 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/dcc1541b-8edd-4e8f-9565-e36978f5e3fcn%40googlegroups.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/tmux-users/dcc1541b-8edd-4e8f-9565-e36978f5e3fcn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> -- 
>>>> 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/9db74581-2cff-4403-8eb8-6646ccba0bc0n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/tmux-users/9db74581-2cff-4403-8eb8-6646ccba0bc0n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/tmux-users/31f8997a-fd50-4e5d-895b-79be1f7e2bd1n%40googlegroups.com.

Reply via email to