Re: why does git set X in LESS env var?
- From
- Dragan Simic <dsimic@manjaro.org>
- Date
- Oct 12, 2023, 22:36 UTC
- Message-ID
- <60f1922b12a6ef304ffa36c334348e34@manjaro.org>
- In-Reply-To
- <c6cd3133573d5ade6d02b5da1051853a4b3885e1.camel@scientia.org>
On 2023-10-12 23:48, Christoph Anton Mitterer wrote:
Show 15 quoted lines
> 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.
Show 7 quoted lines
> 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.
Show 9 quoted lines
>> 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.
Show 7 quoted lines
> 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.
Show 8 quoted lines
>> 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.