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

From: Dragan Simic <dsimic@manjaro.org>
Date: Oct 12, 2023, 00:06 UTC
Message-ID: <ace230a469fabbbbceb38cc884a40b4c@manjaro.org>
In-Reply-To: <fbb3c2bf1c832f0f16cb913da6b862dd313359ef.camel@scientia.org>

On 2023-10-12 01:43, Christoph Anton Mitterer wrote:

Show 12 quoted lines

> On Thu, 2023-10-12 at 01:29 +0200, Dragan Simic wrote:
>> I'm not sure what do you mean by the non-cleared remains being
>> chopped
>> off...  Could you clarify that a bit, please?
> 
> Well if I do say:
> $ reset
> $ git diff HEAD~10
> 
> and from there scroll down a bit and then q to exit less (and the
> screen is not cleared), I see the output only so far as I've had
> previously scrolled down in less.

There's also scrollback in the terminal, which can be used to show more of the contents that was displayed before exiting the pager.

> Everything that would have come after that is of course not visible.
> The place where I exited may be some "well defined" border, like the
> end of a commit... or anywhere it the middle of a patch (making the
> left over remains on the terminal perhaps even ambiguous).

If you didn't select some line or page to be displayed, by scrolling within the pager, it obviously isn't going to be displayed, which is the whole point of using a pager instead of "spitting" the whole contents out at once.

Where and when you exit the pager is up to you only, and you can decide what will be left on the screen at that point.

> What's worse, when (in less) I scroll down and up again, perhaps
> repeating several times, and then quit... I see (at least in my
> less/terminal combination) things twice and mangled up (i.e. when I
> scroll up the terminal (outside of less)).

That sounds like some issue with your terminal or terminal emulator, which should be debugged and fixed separately. Such misbehavior isn't supposed to happen at all.

> So AFAICS, not clearing the screen only works properly when never
> scrolling up again (in less).

It works just fine for me, for example. You're obviously having some unrelated issues with your terminal emulator.

Show 26 quoted lines

>> As I already mentioned above, everyone is free to configure the pager
>> behavior in any way they like.
> 
> Sure :-)
> 
>> 
>> > > Exiting if less contents than one full screen was displayed (i.e.
>> > > "-
>> > > F")
>> > > is there to save people from the frustration of quitting a pager
>> > > that
>> > > actually wasn't needed to be executed.
>> >
>> > Same actually here, at least strictly speaking, ... though I (and
>> > probably everybody else?) would really hate it, if that was
>> > removed. ^^
>> 
>> I'm afraid that I don't understand very well are you complaining
>> about
>> the presence of "-F" or not?
> 
> No :-) As I've said, I like it that way and I and probably everyone
> else would be annoyed, if -F was not present.
> 
> I just meant that strictly speaking the same reason why "S" was
> removed, could be applied to "F" as well.

I see. Actually, removing "-S" was a good decision, IMHO, because chopping long lines isn't something that a sane set of defaults should do. Many users would probably be confused with the need to use the right arrow to see long lines in their entirety.

> It is - like -R - not necessary for less to work with git.
> 
> But it is, of course, what virtually everyone will want in practise.

Well, "-R" is pretty much mandatory, because coloring the outputs has become some kind of defacto standard, and it's very useful when viewing diffs, for example.

Show 10 quoted lines

>> Quite frankly, I can't stand scrolling in less(1) using the mouse
>> wheel,
>> but I do understand why some people like it.
> 
> The main reason I want it is, that things don't get messy, when I
> forget being in less and mouse scroll. ;-)
> 
> 
> Thanks,
> Chris.