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}".
On Thu, 8 Jun 2023 at 10:06, Nicholas Marriott <nicholas.marri...@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 <michael.gr...@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+unsubscr...@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/CAEdLfcFYRk9hsn3DD2ATt2HqZGwWnh-KjuekxkSrxmwJVckTgw%40mail.gmail.com.
