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.
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.
When you get into the terminfo entry definitions, the root cause is that
the terminal initialization sequences contain switching to alternate
screen, which causes screen contents to be lost when less(1) exits.
Thus, "-X" has been actually abused in the pager setups to skip the
terminal initialization sequences, which may also result in other
issues.
Right - this is something that rxvt-unicode addresses with the correct
settings.
IIRC I disabled the secondasyScreen to be able to use the scrollback
buffer (unavailable otherwise), which probably also means that with it
enabled I would also have no issue without -X, but that would need
testing. Also note that rxvt-unicode has its own terminfo file
(xfce4-term uses xterm), and in some places I'm forced to use xterm as a
fallback I get issues like current screen being wiped when switching
to/from secondary screen.
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...
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).
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).
Regards.
--
Thomas
