Re: why does git set X in LESS env var?

[Dragan Simic <dsimic@manjaro.org>]

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.