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.
