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

> On 2023-11-02 10:19, Dragan Simic wrote:
>> On 2023-11-02 14:19, Thomas Guyot wrote:
>>> That's correct, you need both and also -y0
>> 
>> Hmm, I tried the following:
>> 
>>       GIT_PAGER='less -R -F -X -c -y0'
>> 
>> In my environment (Xfce), the result after scrolling the output of 
>> "git
>> log -p" up and down a bit was about 20 copies of the same screen 
>> "page"
>> in the scrollback, plus a couple of blank "pages".  Not good,
>> unfortunately, and actually much worse than having just "-R -F -X".
> 
> Indeed, I did notice it with xfce4-term - I suspect different controls
> are used to clear the screen, with rxvt-unicode the initial one
> scrolls anything in the current display to the scrollback (which is
> important to avoid clearing the last commands/output form the
> scrollback), but afterward screen updates do not update the
> scrollback, it remains within the screen.
> 
> These options may actually affect the behavior (I have put my current
> values there)
> 
>     secondaryScreen: True
>         Turn on/off secondary screen (default enabled).
> 
>     secondaryScroll: True
>         Turn on/off secondary screen scroll (default enabled). If this
>         option is enabled, scrolls on the secondary screen will change 
> the
>         scrollback buffer and, when secondaryScreen is off, switching
>         to/from the secondary screen will instead scroll the screen up.
> 
> So it appears I could disable secondaryScroll to avoid getting
> scrolled lines into the scrollback buffer. It's also noteworthy that
> with secondaryScreen disabled, rxvt-unicode instead scroll things up
> to avoid the current screen form being wiped out.

>>> 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.
>> 
>> Does the GIT_PAGER setup, as I described it above, work for you 
>> without
>> the described artifacts, in any of the environments you have access 
>> to?
> 
> Yes, rxvt-unicode, with the settings mentioned above.

>> One of the solutions is to edit the terminfo entry manually and remove
>> the escape codes that cause the switching to and from alternate 
>> screen,
>> which I tested, but that also introduced another issue -- the screen
>> contents was always present after less(1) exited, which isn't always 
>> the
>> desired behavior.
> 
> But when less scrolls down (line by line, not page by page), it always
> append lines and let them scroll up. Won't you see these?
> (page-by-page otoh will redraw the full screen without scrolling).
> 
> Also won't it wipe the *current* screen so that you won't see the
> commands/output you had *before* running less?
> 
> This is why rxvt-unicode has an option to disable secondary screen,
> and scroll contents all the way to the buffer on switch to/from
> secondary screen.

>>> 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
>> 
>> Please test the "--redraw-on-quit" option, so far it's the best
>> available solution, IMHO.
> 
> I will, not now though - need it compile less form source I guess...

>>> 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).
>> 
>> Quite frankly, I think that such a solution would be like "fixing the
>> fix, which is actually an abuse", as I described it above, eventually
>> introducing even more issues, instead of solving the original issue.
> 
> I'll let you know my findings... I'm not convinced --redraw-on-quit is
> actually going to fix it for all unless this does a lot more than the
> option name implies (but quite happy if it does).