Re: "less -F" is broken

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Aug 16, 2018, 17:10 UTC
Message-ID: <CA+55aFzutOgNbw2jeKox81-9O4+eSDntgrSAqaZrf0-28sTSUg@mail.gmail.com>
In-Reply-To: <e7fb0ae0-b3e3-d7ad-7f6e-c114ee563d59@greenwoodsoftware.com>

On Thu, Aug 16, 2018 at 9:50 AM Mark Nudelman <markn@greenwoodsoftware.com> wrote:

>
> So I'm not sure what the best solution is.  Linus's proposal to disable
> the line counting stuff if -X is set seems reasonable.  I will look into
> that and see if there are any issues with it.

One option that I didn't try to go for - because I just don't know the less code base well enough - is to basically make the behavior of '-F' be something like this:

 - as long as all the lines are short and well-behaved, and we haven't
seen enough lines to fill the screen, act like 'cat' and just feed
them through

 - when you fill the screen (or when you hit some other condition that
makes you go "now I won't exit" - that could be a long line, but maybe
it could also be the user giving keyboard input for a less command?)
you send the init sequence and just redraw the whole screen.

That sounds like the best of both worlds.

In fact, right now "less -F" is in my opinion a bit broken in other ways that my patch doesn't fix.

Do this:

    (echo 1; sleep 10; echo 2) | LESS=FX less

and with my patch it will show "a" immediately. So far so good.

But let's say that that was all the user was interested in, and the user presses 'q' to quit less. That doesn't work at all - it will wait for that full ten seconds.

That actually happens even without -F too.

Wouldn't it be good to react to things like searches to highlight something (and to 'quit' for the 'never mind, alteady got it' case) even if there isn't enough data to fill the whole screen yet?

that said, ^C works, and this is not new behavior, so I'm just throwing this out as a "maybe a different approach would fix _both_ the -F behavior _and_ the above traditional issue"?

                        Linus