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

[Dragan Simic <dsimic@manjaro.org>]

On 2023-10-12 01:43, Christoph Anton Mitterer wrote:
> 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.

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

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