From: Dragan Simic Date: Thu, 12 Oct 2023 22:36:33 GMT Subject: Re: why does git set X in LESS env var? Message-ID: <60f1922b12a6ef304ffa36c334348e34@manjaro.org> In-Reply-To: On 2023-10-12 23:48, Christoph Anton Mitterer wrote: > On Thu, 2023-10-12 at 23:15 +0200, Dragan Simic wrote: >> >> Ah, I can finally see what are you talking about...  Thank you very >> much >> for all the testing you've performed and for supplying this screen >> recording!  I can confirm that my environment is also affected, but >> for >> some reason I haven't observed it this way before. > > Well... perhaps because it's not really "easy" to spot unless one > carefully reads through the lines (which I guess, one does not that > often in the terminal "history"). > > Have a look at my ticket at less, especially: > https://github.com/gwsw/less/issues/445#issuecomment-1758887183 Great, thanks, it's full of very useful information. > Where it was confirmed that the issue I describe might happen (and I > guess is non-fixable? > > The whole issue also contains an explanation on why scrolling doesn't > work when -X is used (but --mouse is not) on VTE terminals (and maybe > others, though not xterm). > And it's basically not "fixable" but simply "by design". It seems that "--redraw-on-quit" is a possible candidate for replacing "-X" in the set of default options for less(1), and also in other CLI utilities, but I still need to test it in detail. >> Huh, that's really worrisome and I'm willing to help you with >> debugging >> and fixing this issue.  Please, let me perform some debugging and >> digging around, and I'll come back to you with some further insights, > > Well, my assumption (though I'm really not a terminal expert) would be > that it's not fixable... because less would somehow make sure that > everything it prints (in the alt screen buffer) is properly > concatenated in the the regular one. I did some work on terminal emulators, but I'm also not very much of an expert when it comes to terminal emulators. > less upstream made some suggestions: > https://github.com/gwsw/less/issues/445#issuecomment-1759986293 > > One would be to change the terminfo entry, which I guess is not really > feasible as a general solution. > > The other would be less’ --redraw-on-quit option. I agree that the latter seems like a viable solution, but as I already wrote above, I need to test it first, together with doing some digging through the less(1) source code. > Maybe that would be an even better solution for git? > AFAICS, we could have -F, the VTE mouse scrolling out of the box, plus > (via that option) the final screen buffer of less printed when exiting. Exactly, but still needs testing and a detailed insight. > Would give some context (what one did in the pager, where one was) on > the regular screen buffer, but (presumably) avoid that mess up... and > perhaps even prevent unneeded pages of output from the pager, if one > scrolled down a lot, which maybe aren't even needed? Yes, it seems to tick all the boxes. > (Also note, that less` upstream calls `-X` "a risky flag" ;-) ) In general, "-X" seems to be more of a bandaid option. >> Those people, just as anyone else, can use $PAGER or $GIT_PAGER to >> configure the pagination the way they like it.  In the end, that's >> also >> what I do in my environment. > > Sure... all I said, that (IMO) in the case of `-X` it's not like with > `-R` but rater like with `-S`... i.e. neither mode has more right to be > the default than the other.