less -FRX drops keypresses when not paging due to -F

[divVerent]

In the past, when less -FRX was used (such as default in git's and hg's pager invocations), if the output was short, and no paging was necessary, keys pressed during the command invocation ended up in the shell prompt.

Now, less -FRX drops a single keypress typed during this time.

Repro:

$ { echo x; sleep 1; echo y; } | ./less -FRX

Then hit enter, and immediately type 1234 before the next prompt appears. The prompt will show just 234.

I bisected the issue to

commit b17b0802471c8b30d4f2f5085f621a5ea9e2d052
Author: Mark Nudelman <[email protected]>
Date:   Wed Nov 16 15:19:28 2022 -0800

    Fix problems with EOF after new poll behavior
    in 953257f9030d29dd930ed3e76fd5811681b672b1.

but also uncovered other broken behaviors along the way in history:

• The version just before this commit doesn't eat keypresses, but it also leaves out the last line (the y) in my example from the output. That's the bug this commit fixed, I suppose.
• Some newer versions actually eat all keypresses while less runs, and shows a prompt that one can cancel using ^X. In a way that's actually better, as it at least shows some UI making one "expect" this behavior.
• In current master, I get yet another different behavior: less now eats all keypresses too, and starts its : prompt - which means that if any key was pressed while less runs, the command won't exit at all until one exits that command line again.

Can we somehow get the old behavior restored, as it fits much better into tools like git and hg where the user often knows in advance whether the output will be more or less than one screen, and can continue working accordingly without waiting for the pager, whereas these tools like to just send ALL their output to the pager unconditionally, as they can't know in advance whether it'll be short or long?

If not, I'll probably have to write my own wrapper that first reads the first screenful, prints it to the screen, and once more data arrives, actually invokes less on this data + anything more coming in. Seems overly complex to have to do that, as the whole point of -F aka --quit-if-one-screen is to do just that...

[gwsw]

I can't reproduce this from your description, but it sounds like the same issue as #557. Is it resolved if you use the --no-poll option?

[divVerent]

Confirmed that --no-poll restores the good behavior. Sadly it's not available on the systems I need it, but it's not like it's hard to install my own build of less.

Long-term, this behavior should probably somehow be made default when less is invoked by hg or git. Any chance there's already a way to do this without causing confusion on systems that don't have the new flag?

[rpolzer@prescottfeuer less (git)-[master]-]$ echo 42 | LESS='--no-poll' /usr/bin/less -FRX          
There is no no-poll option ("less --help" for help)
Press RETURN to continue 
42

Basically, I'd like to have something I can use to send a PR to git and hg projects to restore the default behavior for their commands that always implicitly invoke the pager with these options so that the pager is only "used when necessary".

I guess one could always make hg and git parse less --version first, but that's kinda annoying. Any chance older binaries already have some hidden way to skip this "Press RETURN to continue" prompt for unknown options?

[divVerent]

I should add: using the lesskey mechanism to always set --no-poll system wide isn't really a good idea. This should only apply to invocations that use -F too, like the ones by version control systems.

Maybe you can also add a LESS_NO_POLL env variable that can also activate the effect of --no-poll? Then we could just make git and hg set the variable, and older versions of less will silently ignore the env variable they don't care about.

Or maybe, more generically, I really want a LESS_OPTIONAL variable that behaves like LESS, except that unknown options in there are silently ignored?

[divVerent]

Confirmed

[pager]
pager = LESSKEY_CONTENT="$LESSKEY_CONTENT;#env;#version>=668 LESS=\${LESS} --no-poll" less -FRX

working in my .hgrc, and it should also preserve existing use of LESSKEY_CONTENT, so it might be good enough to suggest to the hg project as a new default. Not sure if using that variable breaks existing users of the LESSKEY or LESSKEYIN variables. It definitely sets the env variable right, as validated by checking /proc/.../environ on the less process.

Didn't yet port this setting to git, where there may be a different escaping hell to get past ;)

[divVerent]

git seems to need:

[core]
        pager = "LESSKEY_CONTENT=\"$LESSKEY_CONTENT;#env;#version>=668 LESS=\\${LESS} --no-poll\" less"

Again confirmed correct via procfs.

[gwsw]

Seems like this is resolved. Any changes to git or other programs are up to the developers of those programs of course, although I would hope they will make any such changes optional, for those of us who do not want the --no-poll behavior.

[divVerent]

Resolved by a change that restores the previous default (if so, which commit?), or resolved by doing nothing and expecting third party tools to add special logic for compatibility to newer less?

[gwsw]

I had intended the latter (the user would use --no-poll when they want this behavior), but after reconsideration I have made a change (52b2d92) that disables polling when -F is in effect and the file is short. I think this eliminates the need for the --no-poll option and I plan to remove it soon.

[divVerent]

Thank you! Much appreciated.

As for the option, if some people really want ^X to be understood during the initial phase of -F, maybe the polling option should be a tristate (i.e. -F changes the default, but --poll and --no-poll override it)?

Personally though, I do not think many people will want both -F and ^X support at once, as the whole point of -F is to not have any user interface if the input is short (e.g. tailing a slowly growing file into less works just fine without -F, so it's not like using -F unlocks any features beyond returning to the shell quicker).

[gwsw]

Yes, I agree that it's unlikely that a user would want to input ^X or other keys while -F is in effect for a short file. When displaying such a file, less will exit immediately after printing the file contents, so there would be only a small fraction-of-a-second window in which the user could enter anything. That's why I think that --no-poll is no longer needed.