Can not select text from a "git log" viewed in a terminal pane ("less" goes refreshing like crazy)

[jimklimov]

The display with "less" (I assume, as PAGER) wrapping the git log output keeps re-rendering (blinks occasionally). I can not select the commit IDs to copy-paste into another terminal pane.

Probably related to this, a git show of a large commit (bigger than screen so PAGERed) seemed okay interactively, but filled the whole scrollback buffer with copies of the text quickly.

With explicit PAGER=more git (somecmd args...) these effects are not seen, but it is a much less capable viewer so undesired :)

I would assume something posts terminal size changes to less over and over.

It may be a platform issue (recent rolling release of OpenIndiana) so would be nice to hear from other OSes if they can reproduce it.

[kuthulux]

it works fine here in ubuntu 18.04 and 20.04

[jimklimov]

Thanks. FWIW, I started git log in one pane and traced the less -ins it spawned from another, it loops rapidly with:

    Received signal #20, SIGWINCH, in read() [caught]
read(3, 0xFFFFFD7FFFDFF40F, 1)                  Err#4 EINTR
lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000, 0x00000000, 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
sigaction(SIGWINCH, 0xFFFFFD7FFFDFED50, 0xFFFFFD7FFFDFEE00) = 0
lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000, 0x00000000, 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
ioctl(1, TCGETA, 0xFFFFFD7FFFDFEB80)            = 0
ioctl(1, TCGETA, 0xFFFFFD7FFFDFEB10)            = 0
ioctl(1, TIOCGWINSZ, 0xFFFFFD7FFFDFEB88)        = 0
ioctl(2, TIOCGWINSZ, 0xFFFFFD7FFFDFEC48)        = 0
write(1, "1B [ H1B [ 2 J1B [ H1B [".., 1023)    = 1023
write(1, " o r t   f o r   c m a k".., 658)     = 658

as I wildly-guessed above.

Just doing a less /some/long/file or ls -la /etc | less does not do this - it just processes the events as they come and quiesce. Manually piping even to the same command line as spawned by git does not do this: ls -la /etc | /usr/bin/less -ins so I am lost how all this magic works :\

[jimklimov]

Tried a bit more. The default TERM=xterm-256color and any other TERM=xterm* value I tried afterwards had this effect of infinite looping for git using the PAGER=less (or just the default PAGER it defines to call less).

With TERM=ansi, or vt100, or vt200, there are no issues like this. There is a SIGWINCH (and a re-render, I believe) when the mouse enters this pane or exits it, or when I scroll with the wheel. But otherwise no madness like that with xterm.

This is then a problem of... I don't know whom to finger-point :) git? less? ncurses? terminfo? OpenIndiana somehow mangling these?..

[jimklimov]

Of these, TERM=ansi behaves a bit crazy when I "remember" longer-than-panewidth lines from bash history, they begin to scroll up endlessly :\ I guess I will try to force export TERM=vt220 from my desktop icon wrapper as the least faulty option seen so far...

UPDATE: The caller's TERM is ignored, it is explicitly set in addTab() in GCM. Hm, and even there, even if I trace with hi-tech print("stuff...") that the TERM is vt220 (exported from caller, and then set explicitly in code), the launched local or SSH session starts with xterm-256color anyway :\

[jimklimov]

The PR above should take care of passing the specific TERM value requested by code (hardcoded to xterm-256color in your GCM, fixed to vt220 in my packaging) into the local or SSH session made by vte_run().

Also checked that an SSH session to a Linux machine does not suffer the problem with git log I saw on OpenIndiana natively, so something differs outside of GCM and GTK to break the pager... At least, this (mis-)behaved reminiscent of Midnight Commander in GCM on OI not using the mouse after some OI updates last year, while it worked well in SSH sessions to Linux. And in mate-terminal on OI. Go figure...

[jimklimov]

Stalemate :\ With TERM in vt100, vt220, ansi - midnight commander does not like the mouse. There's just a few hundred terminfo's to pick from...

UPDATE: Over 2500 in fact...

But got a hit rather quickly, screen-256color works well for at least both mc with mouse, and git log with default and with unset PAGER.

[kuthulux]

maybe it has something to do with the WINCH event in the ssh.expect script.

 set rows [stty rows]
 set cols [stty columns]
 stty rows $rows columns $cols < $spawn_out(slave,name)
} WINCH```

that code detects the window resize and then change the tty accordingly.
you can try commenting out that block to see if that helps, if so then maybe we can compare the actual rows and cols and of the tty and only if there is a change set the new size.

[kuthulux]

we can introduce a new config field for setting the term value, by default just using the one in the environment.

[jimklimov]

Also a good idea. Potentially can even set one per host config, to override the "global default" configured value. But other than praising the idea, I am not likely to progress far and fast on it myself anytime soon, got too much backlog everywhere :(

[jimklimov]

Commenting the block in ssh.expect did not help, neither in Local session (makes sense) nor in "ssh to localhost" session.

[kuthulux]

maybe this issue is related to #51 , can you take a look there?

[jimklimov]

Can't confirm or deny if that exact fix was related, but with current Git HEAD (from 2021-04-20) I thankfully can not reproduce the refresh madness. It seems that somehow the terminal also drove the ksh93 (as system shell) nuts, so it crashed in random places when under stress (e.g. running configure scripts), which was not reproducible with other terminal emulators on same or other systems - and seems not reproducible with new GCM.

On the downside, now as a user of Midnight Commander (though rarely navigate it with a mouse) I can confirm issue #64 appeared, and was not in 1.2.1 release.