Skip to content
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

An action bound to the ESC key doesn't execute immediately #83

Open
numirias opened this issue Oct 18, 2020 · 7 comments
Open

An action bound to the ESC key doesn't execute immediately #83

numirias opened this issue Oct 18, 2020 · 7 comments

Comments

@numirias
Copy link
Contributor

numirias commented Oct 18, 2020

Bug
I want to quit less by pressing ESC, so I added this to my ~/.lesskey file:

#command
\e quit

However, when I now press ESC, nothing happens yet. Only when I press the key twice, the action triggers and less quits.

Cause
In command.c:getcc(), less scans the command character stream to replace the kent (Keypad Enter) sequence with a newline character. In consequence, any key sequence starting the same way as kent is not processed any further yet, until the loop in getcc_repl() has concluded that it doesn't match.

Since on my machine, kent is \eOM, any key sequence starting with \e or \eO is not handled immediately. So, pressing \e doesn't trigger any action until I add another character that breaks the kent sequence.

Workaround

Since kent gets its value from the termcap entry @8 (screen.c:1212), it's possible to force it to another value via e.g. this .lesskey entry:

#env
LESS_TERMCAP_@8 =

However, it would be great to not have to use this workaround. A fix could involve checking if there is a key bind shorter than the replacement sequence, in which case the replacement attempt is skipped and the characters are forwarded immediately.

@gwsw
Copy link
Owner

gwsw commented Oct 31, 2020

I'm not sure that assigning a command to ESC is a good idea, even if this issue were addressed. On most terminals, several commonly used keys send sequences beginning with ESC. So less would exit if you pressed any arrow key, ENTER, HOME, END, etc. as well as any mouse movement if you are using --mouse.

@gwsw gwsw added the question label Nov 19, 2020
@polluks
Copy link
Contributor

polluks commented Nov 28, 2020

I'm not sure that assigning a command to ESC is a good idea, even if this issue were addressed. On most terminals, several commonly used keys send sequences beginning with ESC. So less would exit if you pressed any arrow key, ENTER, HOME, END, etc. as well as any mouse movement if you are using --mouse.

Indeed, however my system uses 8-bit CSI so there would be no ambiguity.

@gwsw gwsw removed the question label Nov 29, 2020
@gwsw
Copy link
Owner

gwsw commented Jan 3, 2021

When you say your system "uses 8-bit CSI", do you mean that your terminal sends 0x9B instead of 0x1B as the initial character of an escape sequence? If so, why does your termcap say kent is \eOM? Isn't this a configuration error of some kind?

@polluks
Copy link
Contributor

polluks commented Jan 3, 2021

This was a special case, my kent sends a simple CR therefore no escape trouble at all.

@gwsw
Copy link
Owner

gwsw commented Jan 11, 2021

I'm sorry, I'm still confused. Are you saying that the ENTER key on your terminal sends '\r' but your terminfo says that it sends a sequence containing an ESC? If so, the solution would be to make your terminfo match your terminal.

@polluks
Copy link
Contributor

polluks commented Jan 12, 2021

I cannot distinguish return and enter, but it doesn't matter. Back on topic: Most of my GUI apps close by Esc (not alt f4), however console apps work differently.

@bew
Copy link

bew commented Jun 25, 2022

FWIW An alternative I use is:

#command
\e\e quit

#line-edit
\e\e abort

Bind Escape-Escape to quit, and Escape-Escape to abort line editing (to cancel a search for example).

This way the binding is explicit, and I just rely on it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants