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

> On 2023-11-02 02:48, Dragan Simic wrote:
>> On 2023-11-02 06:48, Thomas Guyot wrote:
>>>         -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".
> 
> That's correct, you need both and also -y0

>> 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?
> 
> Indeed, but when less update from the bottom, it can add new lines and
> let the overflow lines scroll up into the scrollback buffer.
> 
> Then updating it from the top, it draws the whole page, top to bottom.
> That's fine for a full page but not desired for a partial one. Also
> note that on my terminal (rxvt-unicode) when less clears the screen to
> draw the first page the current screen is rolled up into scrollback -
> iirc that's a configurable option, it would be worth testing other
> terminal's behavior on that. IIRC it may also erase it when using the
> wrong termcap file.
> 
> I haven't looked at the code, but I think it could be possibly to
> start the -c behavior only after a full page is drawn, after exiting
> on partial pages, which would give us the best of both worlds.

>>> 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).
> 
> TBH I haven't tested --redraw-on-quit, even on Debian Bookworm which
> was just released a couple months ago this option isn't available. I
> suspect that the issue isn't -X, but the scrolling behavior controlled
> by -y and the full redraw controlled by -c.

> Actually I just tested my
> solution on xfce4-terminal and it doesn't work, the terminal still
> push up stuff above on redraw (noteworthy is with rxvt-unicode the
> first draw pushes the current screen contents up but no other redraw
> does, which is what makes it work so well - I haven't tried to find
> out what is being done exactly... OTOH the redraw on scroll down is
> slightly noticeable there, while impossible to see on xfce4-terminal.
> I'll install the latest less and see what happens with --redraw on

>>> 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?
> 
> I mentioned it slightly above, to be clear it would mean that:
> 
> 1. less starts by just writing lined down as usual, making any lines
> above scroll up and overflow into the scrollback buffer as usual
> 2.  If less draws less than a page, exits as before - the effective
> result is as if pager was cat
> 3. If less reaches a full page and still has lines to write, it turns
> on -c's behavior and further updates happen from the top of the
> screen, preventing scroll up (at least on rxvt-unicode)
> 
> Now, if all other terms misbehave here, that's an issue, making this
> suggestion mostly useless. And considering the number of Windows users
> we absolutely need to test Windows Terminal, and should probably test
> MacOS's term too (whatever that is).

>>> 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).
> 
> Feel free to cc me on your next correspondence. If there are mailing
> lists archives for the thread I'll fetch them as needed. We have at
> least one working term/switch combination, which IMO is a better start
> than nothing :)