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

[numirias]

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]

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.

[polluks]

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]

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]

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

[gwsw]

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]

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]

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