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

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

 



On 2023-10-12 22:23, Christoph Anton Mitterer wrote:
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,

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.

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.




[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