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

From: Dragan Simic <dsimic@manjaro.org>
Date: Oct 12, 2023, 21:15 UTC
Message-ID: <31b6f4a2b88cc3a2cfa908f82f4f2302@manjaro.org>
In-Reply-To: <e1e187ca3d970c18e1a11d51ff93b6cb212bcbaa.camel@scientia.org>

On 2023-10-12 22:23, Christoph Anton Mitterer wrote:

Show 28 quoted lines

> On Thu, 2023-10-12 at 07:46 +0200, Dragan Simic wrote:
>> Let me repeat that the messed up output you're experiencing isn't 
>> normal
>> and has nothing to do with the arguments passed to less(1).  That's a
>> separate issue of the terminal emulator(s) you're using, or in issue 
>> of
>> your specific environment, and should be debugged and addressed as a
>> separate issue.
> 
> As I've told you before it happens at least in gnome-terminal (and thus
> presumably and VTE based terminal), xterm, xfce4-terminal and konsole
> (all current versions of Debian unstable)... with less as of Debian
> unstable as well as 643.
> 
> That affects at least on major distro, and there's a good chance that
> it affects any other distro based on Debian (*buntu, etc.).
> 
> I further tried on SLES 15 with both gnome-terminal 3.42.2 and xterm
> 330 as well as less 530.
> 
> Even tried with the terminal emulator started via env -i and only TERM
> set manually.
> 
> *All* cases affected by the same problem I've described before.
> 
> Same with the command you've used in your follow-up post, here a video
> of it in HD:
> https://youtu.be/MsxtQgrKM50

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.

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,

Show 11 quoted lines

>> To me, having inconsistent displaying of the short and long outputs
>> is simply not acceptable.
> 
> Which is fine - and as I've said: I personally also tend to prefer it
> like that - but even if the above would be just some bug (which however
> seems to affect all systems I could test on a short notice, except
> yours)... one can IMO still not generally say whether on or the other
> behaviour is generally accepted to be the better one.
> 
> Even if output may be just chopped of and thus ambiguously incomplete,
> some people may still prefer to have rather no output at all.

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.

Show 7 quoted lines

>> Perhaps something is wrong with your specific environment, because
>> I see no other reason for this issue.
> 
> Well may be, but seems unlikely from my PoV, given that I've now tested
> even on other distros and systems not under my control.
> 
> Anyway... I think this got a bit too off-topic here :-D

Well, yes and no. This scrolling-related issue is obviously affecting numerous git users, which makes it quite relevant for git as a project. Of course, not directly relevant, but indirectly, yes.