tmux can't use triple click to select line. add \33[12;1H \33[13;1H between long text in one line

[askgh]

i use bash to print one lone text in a line. i can't use triple click to select the whole line
i use strace to record the writev of tmux server and found tmux add \33[12;1H \33[13;1H between long text in one line

like this
1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111\33[11;1H111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111\33[12;1H111

in win10 os, and xshell app

details is in gif

[nicm]

Am I meant to guess the tmux version?

[askgh]

Am I meant to guess the tmux version?

$tmux -V
tmux 3.2-rc3

[nicm]

Can you run with -vv and show me the server log please?

[askgh]

the log of tmux -vv a -t one

[nicm]

This is the client not the server log, you need to kill tmux entirely and run with -vv. Also please attach it to the issue rather than pasting it into a comment.

[askgh]

tmux-server-20959.log
this is the log of the server. it reproduce

[askgh]

in the log. is this place. the tmux server split the long text on a line

1610889135.959714 /dev/pts/0: 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
1610889135.959719 tty_clear_pane_line: /dev/pts/0, 212 at 0,46
1610889135.959723 tty_clear_line: /dev/pts/0, 212 at 0,46
1610889135.959725 /dev/pts/0: \033[47;1H
1610889135.959730 /dev/pts/0: \033[K
1610889135.959735 /dev/pts/0: 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
1610889135.959739 tty_clear_pane_line: /dev/pts/0, 212 at 0,47
1610889135.959741 tty_clear_line: /dev/pts/0, 212 at 0,47
1610889135.959744 /dev/pts/0: \033[48;1H
1610889135.959747 /dev/pts/0: \033[K
1610889135.959751 /dev/pts/0: 1111111111

[nicm]

OK I will look during the week.

[nicm]

tmux has to clear the line, and that means moving the cursor. But I don't think we need to clear immediately if the new text is going to overwrite at 0 anyway. Does this make any difference? x.diff.txt

[askgh]

tmux has to clear the line, and that means moving the cursor. But I don't think we need to clear immediately if the new text is going to overwrite at 0 anyway. Does this make any difference? x.diff.txt

still has this problem. make sure the patch has compiled

strings /proc/3571487/exe |grep 'clearing at'
clearing at %u

[askgh]

use tmux to scrool up cursor to show the history of the screen, can easy reproduce this bug

[nicm]

Oh in copy mode it doesn't really worry about it at all, it isn't really expected to work.

[nicm]

Show me a log from reproducing with the patch applied please, not using copy mode.

[tty5]

Show me a log from reproducing with the patch applied please, not using copy mode.

i use patched tmux. after using half working day. has not beed reproduce this problem

do u need log that havn't reproduce. so the log is not useful

[nicm]

No only show log if you can still reproduce outside copy mode.

[tty5]

No only show log if you can still reproduce outside copy mode.

ok.
thanks a lot for resolve this problem

[tty5]

No only show log if you can still reproduce outside copy mode.

so i think that tmux show a long text in one line in copy mode still has problem.

will it be fixed in the furture?

[nicm]

Maybe, I will have a look and see if it can. But I am not too worried about this TBH because it will never work with multiple panes, it is better to focus on making tmux's own mouse support work better.

[askgh]

i think tmux's own mouse only can be used in tmux. paste in tmux. can't copy out

there are many scenario that use ssh client to connect linux in windows os. like win10

so need copy some lines of the histroy of a pane out to windows app is a frequent ops.

if use the multiple panes. the tmux resize command can make a pane max window size.

if the bug still in the copy mode. programmer can't copy the lines out to other app. or the copyed text is wrong

thanks

[nicm]

You can copy out if you use a terminal which supports OSC 52.

[askgh]

it limits tmux's world wide used

help tmux better, it is a very useful tool. it will be used by many ten years

[nicm]

I have applied a modified version of this diff to fix some problems with it, it will be in GitHub later on when it syncs. Please let me know if you see any problems.

[askgh]

i tested the master branch. and the copy mode is still can't work. is it expect?

the normal mode can work fine

[nicm]

Yes no changes to copy mode yet, I will look at it later sometime.

…

On Mon, 18 Jan 2021, 14:08 ask-github, ***@***.***> wrote: i tested the master branch. and the copy mode is still can't work. is it expect? the normal mode can work fine — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2537 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACKI43EO6YTUA5VLMINJQLS2Q6GTANCNFSM4WGCDGQQ> .

[askgh]

thanks u very much

it make my work easier.

[nicm]

I think that because of how copy mode works it is not practical to change this without major work to how it redraws. I will put it on the todo list but I don't expect it to happen soon, sorry.

[nicm]

I had to revert the previous change because it wasn't working, however here is an updated change which should achieve the same thing (still not copy mode). Please test if possible: tmux-screen-write-trim4-freelist.diff.txt

[tty5]

now, i use commit 8242397, which include your patch
91d112b There is no need to clear every line entirely before drawing to it, this means moving the cursor and messes up wrapping. Better to just clear the sections that aren't written over. GitHub issue 2537.

it is work fine.
so if i can help test. is patch tmux-screen-write-trim4-freelist.diff.txt on 8242397?
or use the branch master to compile tmux and run it

[nicm]

91d112b causes tmux to freeze for some people so I reverted it.

Please pull master and then apply the new patch and try it instead.

[askgh]

91d112b causes tmux to freeze for some people so I reverted it.

Please pull master and then apply the new patch and try it instead.

i test master branch and patch tmux-screen-write-trim4-freelist.diff.txt, it is also work fine.

[nicm]

Great stuff, let me know if you see any problems. I shall probably apply this in a few days.

…

On Tue, 26 Jan 2021, 03:19 ask-github, ***@***.***> wrote: 91d112b <91d112b> causes tmux to freeze for some people so I reverted it. Please pull master and then apply the new patch and try it instead. i test master branch and patch tmux-screen-write-trim4-freelist.diff.txt, it is also work fine. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#2537 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACKI452SFNJ3TY57YMYFT3S3YYDZANCNFSM4WGCDGQQ> .

[askgh]

i use vim to open file and use triple click to select long txt.

can't select the whole line.

so maybe there are some problem on patch tmux-screen-write-trim4-freelist.diff.txt

the log need send later

[nicm]

I see this too but it seems like a problem with vim:

$ perl -e 'print "x" x 1000' >~/xx
$ rm *.log;./tmux -vvLtest new 'vim ~/xx' \; run -d 1 \; send :q Enter

Shows:

1611740720.370086 input_parse_buffer: %0 ground, 1982 bytes: \033[1;1Hxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\033[2;1Hxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\033[3;1H...

So vim is moving the cursor at the end of each line which means it does not wrap.

[nicm]

vim is actually drawing quite strangely, it doesn't move the cursor at the end of the line but instead it draws one more character than the line length, then moves the cursor back:

1611741403.230266 screen_write_collect_end: 107 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (at 0,0)

^--- 107 characters is full terminal width.

1611741403.230291 screen_write_collect_add: wrapped at 107,0
1611741403.230329 screen_write_linefeed: at 107,0 (region 0-81)
1611741403.230352 screen_write_collect_end: 1 x (at 0,1)

^--- It wraps,but then vim sends an additional x.

1611741403.230374 input_csi_dispatch: 'H' "" "2;1"
1611741403.230393 parameter 0: number 2
1611741403.230411 parameter 1: number 1
1611741403.230437 screen_write_cursormove: from 1,1 to 0,1

^--- The cursor is now at 1,1, but vim moves it back to 0,1.

1611741403.230467 screen_write_collect_trim: 0xc3e6b116200 0-0 inside 0-106

^--- tmux discards the stray x because it will be overwrriten by the next line of xxxxx....

[nicm]

It does the same with TERM=xterm so it is not something lacking in the screen or tmux terminfo entry. Maybe it is an attempt to deal with non-am terminals...

Anyway I guess you will need to talk to vim about this, or try neovim and see if it is better.

[askgh]

but run vim in normal shell, not in tmux. the triple click can select the whole line.

the previous patch also can use triple click to select whole line in vim as run in tmux

[nicm]

Hmm you're right, that's weird. I'll take a look.

[nicm]

Try this instead please: tmux-screen-write-trim5.diff.txt

[askgh]

Try this instead please: tmux-screen-write-trim5.diff.txt

tmux-screen-write-trim5.diff.txt is work fine for run vim in tmux

thanks

[nicm]

OK great, let me know if you see any further problems. It will be applied soon.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.