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.
