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

[Dragan Simic <dsimic@manjaro.org>]

On 2023-11-02 06:48, Thomas Guyot wrote:
> On 2023-10-13 16:12, Dragan Simic wrote:
>> On 2023-10-12 18:19, Junio C Hamano wrote:
>>> Dragan Simic <dsimic@manjaro.org> writes:
>>>> Please note that dropping "-X" and leaving "-F" would actually
>>>> introduce the inconsistency that I already mentioned.  To reiterate,
>>>> short outputs would then remain displayed on screen, while long
>>>> outputs would disappear after exiting less(1).
>>> 
>>> Good point.
>> 
>> I've been thinking about this, and a rather elegant, 
>> backward-compatible
>> solution is possible, but it requires some improvements to be made to
>> less(1) first.  I'll reach out to the author of less(1) and propose 
>> that
>> new feature, and I'll let you know his opinion about it.
> 
>  Hey there...

Hello!

> I'm clearly late to the party but I'm wondering, has anyone tested
> adding -cy0 ? From the manpage (slightly edited):
> 
>        -c or --clear-screen ( and backward compat. -C or
> --CLEAR-SCREEN )
>               Causes full screen repaints to be painted from the top
> line down.  By default, full screen repaints are done by scrolling
> from the  bottom  of the screen.

AFAIK, the "-c" option is about the way screen contents is updated when 
scrolled, and it exists to aid in resolving possible issues with some 
terminal emulators.  To make sure, I just tested it, and "-c" doesn't 
replace "-X".

>        -yn or --max-forw-scroll=n
>               Specifies  a  maximum  number of lines to scroll
> forward.  If it is necessary to scroll forward more than n lines, the
> screen is repainted in‐
>               stead.  The -c or -C option may be used to repaint from
> the top of the screen if desired.  By default, any forward movement
> causes scrolling.

This option is, I'd guess, also about aiding in resolving possible 
issues with some terminal emulators.  Or maybe even with some actual 
terminals as pieces of hardware, who knows, which may be too slow to 
scroll many lines at once.

> I actually have one major issue with it, it's that displaying anything
> less than a full page will fill the screen with ~ on the bottom, just
> like when scrolling up on a partial page  without -F. I can see this
> being a major annoyance when using for ex. git log -1, git show --stat
> or --name-only, etc. as I  usually do it to keep the latest history
> within the current screen (and there's likely even commands that I
> never seen using the pager because I never exceeded the page height).

Huh, this confuses me a bit, quite frankly.  Isn't the "-F" option used 
specifically to make pagination invisible in case fewer lines than one 
full screen are displayed?

> OTOH by repainting from the top, the scrollback buffer is never
> affected. only the last displayed page remains on the terminal.

Just to clarify, it's the "-X" option that creates all the issues, and 
the "--redraw-on-quit" option is already there to replace it with no 
associated issues, but the trouble is that only newer versions of 
less(1) support the "--redraw-on-quit" option.  IOW, it's all about 
improving less(1) to avoid complex workarounds required to handle 
different versions, such as the workarounds used in bat(1).

> If less could only enable this behavior after the first full page
> draw, that would be perfect!

Could you, please, elaborate a bit on that?

> Dragan, that may be useful if you're discussing with less
> developers...

We've basically reached some kind of an agreement about the need for a 
good solution, which turned out to be rather complex as a result of 
being quite universal and extensible, which was required for it to, 
hopefully, be accepted into less(1).  Also, the author of less(1) seems 
to be quite busy with some other things, and he prefers to implement new 
features himself.

We've also agreed on another new feature for less(1), hopefully, which 
isn't exactly related, but should be quite useful.  It's about the 
secure mode for less(1).