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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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".


> 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.


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.


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.

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?


(Also note, that less` upstream calls `-X` "a risky flag" ;-) )


> 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.



Cheers,
Chris.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux