-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
less -FRX
drops keypresses when not paging due to -F
#599
Comments
less -FRX
drops keypresses when not pagingless -FRX
drops keypresses when not paging due to -F
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? |
Confirmed that Long-term, this behavior should probably somehow be made default when
Basically, I'd like to have something I can use to send a PR to I guess one could always make |
I should add: using the lesskey mechanism to always set Maybe you can also add a Or maybe, more generically, I really want a |
Confirmed
working in my Didn't yet port this setting to |
Again confirmed correct via procfs. |
In the past, when
less -FRX
was used (such as default ingit
's andhg
'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:
Then hit enter, and immediately type
1234
before the next prompt appears. The prompt will show just234
.I bisected the issue to
but also uncovered other broken behaviors along the way in history:
y
) in my example from the output. That's the bug this commit fixed, I suppose.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.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 whileless
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
andhg
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...The text was updated successfully, but these errors were encountered: