const readline = require('readline');
readline.emitKeypressEvents(process.stdin);
process.stdin.setRawMode(true);
process.stdin.on('keypress', console.log);
After pressing Esc once, I would get this output:
undefined { sequence: '\u001b',
name: 'escape',
ctrl: false,
meta: true,
shift: false }
After pressing Esc three times, I get this output:
undefined { sequence: '\u001b\u001b\u001b',
name: 'escape',
ctrl: false,
meta: true,
shift: false }
It works fine on 0.10.44 and 0.12.13. After pressing Esc once:
{ name: 'escape',
ctrl: false,
meta: false,
shift: false,
sequence: '\u001b' }
Also notice that meta is false here.
I've dug into this a bit and can confirm the bug exists in v4.x and v5.x
It would appear to have been introduced in v2.0.2 I'll dig into that release and see where it came from
So it would appear that escape started acting weird after https://github.com/nodejs/node/commit/aed6bce906 landed.
Doesn't appear to be easily revertable... I'm digging into what is going on with escape
Found the offending section
https://github.com/nodejs/node/blob/master/lib/internal/readline.js#L144-L151
The original PR introduced this logic which yields to more results if the first character is an escape... which is problematic if your entire payload is an escape. It allows for double escaped characters, which is why things work on the third press
Not sure the best way to approach this, but I'll revisit in the morning
@TheAlphaNerd It was mentioned in the PR itself.
@princejwesley sigh... I wish I had read the pr instead of just the commit and then digging into the code.
@cjihrig you have the blame on most of internal/readline.js would you specify this as a wont-fix rather than as a bug?
@TheAlphaNerd I'll fix it!
Sorry I'm late to this party. It looks like a proposed fix is available. But for the record, I don't think this is a won't fix. I don't think we should have accepted the original PR that knowingly broke the Escape key.
@cjihrig I accepted that drawback as the primary use of esc in a terminal is to start an escape sequence, but I now see the issue with applications relying on that key.
@princejwesley I guess a timeout-based approach to triggering the key is the way to go. I just don't know if 700ms is the correct value, seems a tad high.
@silverwind
Default timeout values for zsh is 400ms and for vim & ncurses, its 1sec. @sindresorhus suggested to kepp the middle value between 400 - 1000. Shall I update with the middle value of '400 - 700' (550ms) or 400ms? One second is too high.
How about 500ms, like in GNU readline (http://man7.org/linux/man-pages/man3/readline.3.html)?
@silverwind Done
This has been backported to v4.x in 68a2979b57