Esc to abort is slower than ctrl-c (is this due to esc keys / arrows)?

[jesseleite]

• I have read through the manual page (man fzf)
• I have the latest version of fzf
• I have searched through the existing issues

Info

• OS
  • Linux
  • Mac OS X
  • Windows
  • Etc.
• Shell
  • bash
  • zsh
  • fish

Problem / Steps to reproduce

Esc to abort is slower than ctrl+c. This is especially noticeable in fzf.vim, but I assume is actually related to the delay caused by up+down arrow mappings relying on the terminal sending esc keys? If so, is there a way to disable esc keys (similar to :set noesckeys in vim)? The reason I ask is that I never use my arrows, so it would be nice to get rid of the delay if possible. Thoughts on this? 🙂

[junegunn]

You can set $ESCDELAY environment variable to a smaller value than the default 100.

arrow mappings relying on the terminal sending esc keys

Not just arrow keys. Mouse clicks and scrolls, ALT-* keys, page-up, page-down, home, end, delete, and function keys all start with an ESC. Small delays are known to cause problems on some platforms.

(So why ESCDELAY? Because fzf used to be an ncurses program. See 4342515)

[jesseleite]

Oh interesting... Thanks @junegunn!

[tomstuart]

I’ve tried setting $ESCDELAY to small values (e.g. 0, 1) but it still takes a very long time for fzf.vim to close on esc — I have to wait about a second for it to disappear, whereas ctrl-c is instantaneous. Is there any solution other than learning to use ctrl-c instead?

[iukej]

Same issue as @tomstuart here. Adding

export ESCDELAY="1"

to .bash_profile does not make the ESC abort from CTRL-T as quick as CTRL-C from CLI. It waits for one second before proceeding.

Within fzf.vim, the wait is about 3 seconds.