> 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.
