Escape should close command prompt (vim-like behaviour)

[pinpox]

Similar to #1506, when pressing the escape key while in the command prompt, it should close as it does in vim. This is helpful if you change your mind when entering commands and what to exit the prompt without any changes.

[gahr]

I tend to agree that I would expect escape to close my prompt too. Anyway, ctrl-g does that already.

[steef435]

Per discussion in #1511, I made a hacky (experimental) implementation of this in steef435/neomutt@97e2389 (this one does use a hard coded solution in mutt_getch, and abuses existing infrastructure in km_dokey for letting mutt_getch pass opcodes). While this seems to work on my end, the delay is longer than expected, probably because of the inotify polling which I don't fully understand.

[flatcap]

That's very nice @steef435

I see what you mean about the delay; I couldn't see where that was coming from (but I only had a quick look). If you bind some other key to cancel, the response is instantaneous.

I built without libinotify (./configure --disable-inotify) and that's not the cause.
libinotify is watching the filesystem for changes, e.g. new files.

Please could you look into the delay.
The logging only has second-resolution, so you'll need to be creative!

[steef435]

Ah, thank you!

Apparently curses internally delays escape presses for escape sequences. For ncurses there's the ESCDELAY (see man ESCDELAY) environment variable that influences this timeout. Setting it to 0 makes the Esc detection code work.

However, I then noticed that the general keybindings broke somewhere along the way. Pressing Esc in the default view shows a change folder prompt filled with "ancel>", so most likely, the name of OP_EDITOR_CANCEL gets thrown in the key buffer somewhere.. I intend to continue working on this but it will probably take at least a week until I have time again. (so, if someone feels up to the task..)

EDIT: what I've done so far can be found in this branch: https://github.com/steef435/neomutt/commits/esc-cancel-prompt

[flatcap]

... ESCDELAY ...

Aha!

... the general keybindings broke somewhere along the way
ancel>

Ah, that makes sense. We need to distinguish text-entry from just waiting for a key.
I've suggested to @binaryplease to make that change.

probably take at least a week until I have time again

no worries.

[JJK96]

Any progress on this? Ctrl+g is a lot harder to hit for me than escape.

[flatcap]

Any progress on this?

Unfortunately, not.
We were hoping this would be simple, but it wasn't.

Many functions keys and <Alt>-key generate sequences with Esc in them.
Separating them from a single Esc press would need timing info, which we don't have.

It would still be 'nice to have', but nobody's working on it.

[JJK96]

I've experimented a little bit with the branch of @steef435. I have simplified it a bit (possibly too much, I don't know which problems you ran into).
My branch escapes the prompt if escape is entered on its own, but combinations (if entered fast enough) are sent through (i.e. +c which is equal to +c).

https://github.com/JJK96/neomutt/tree/esc-cancel-prompt

[flatcap]

Thanks, I'll have a closer look later.

[steef435]

IIRC the problem with raising an error in the general mutt_getch is that it interferes with the use of <Esc> in key bindings. In your branch, if you press <Esc> and then <Tab>, the <Esc> will be discarded before <Tab> is pressed and next-new-then-unread (<Tab>) is executed instead of previous-new-then-unread (which is ).

So you would have to know in mutt_getch whether the input is for a prompt (cancel) or not (buffer) to handle it from there, I think. I don't think that's possible right now, and I'm not sure whether it would be neat design if it would be. It would be a lot simpler in this case though!

EDIT: I'm not working on this atm, just some pointers that may help if you want to pursue it further