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.
On Thu, 8 Jun 2023 at 11:04, Michael Grant <michael.gr...@gmail.com> wrote:
> 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?
> On Thursday, 8 June 2023 at 10:32:44 UTC+1 nicholas...@gmail.com wrote:
>
>> 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
>>
>>
>>
>> On Thu, 8 Jun 2023 at 10:27, Michael Grant <michae...@gmail.com> wrote:
>>
>>> 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+...@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
>>> <https://groups.google.com/d/msgid/tmux-users/31f8997a-fd50-4e5d-895b-79be1f7e2bd1n%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/6f993238-b0af-4849-9194-5205cec8c10cn%40googlegroups.com
> <https://groups.google.com/d/msgid/tmux-users/6f993238-b0af-4849-9194-5205cec8c10cn%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/CAEdLfcH0PgG_TC%2BqXWRrdfVQVx5f1itryU3%3Dqke2AuosPR02Ow%40mail.gmail.com.
