readline: turn emitKeys into a streaming parser

[rlidwka]

see #1403

I changed emitKeys to a generator that receives data character by character and emits keypress event whenever an escape sequence is complete.

So now behavior is similar to bash and python shells I tested so far. For example, you can sequentally press ESC + [ + D, and it will be handled the same as "left arrow", because the data that's coming to node.js is the same in both cases: \x1b[D.

Possible side effect: escape key itself will never be emitted. If we get \x1b, parser will treat it as a start of an escape sequence no matter what. Our REPL never rely on that, but maybe other readline users are (xkcd spacebar heating yep).

[mscdex]

What about having a timer that starts when you see \x1b and after 1-2 seconds or whatever of no additional input, it is interpreted as an escape by itself. This is what I've seen in other console-based programs.

[rlidwka]

This is what I've seen in other console-based programs.

I think readline behavior should be consistent with other shells. I just tested bash, irb (ruby shell) and python, and didn't see a timer-based approach.

[mscdex]

Sorry, I was referring to ncurses-based programs and such, not so much shells or other REPLs.

[Fishrock123]

Maybe use a while (ch === '\x1b'), so it will catch as many escapes as one could possibly feed into it?

[Fishrock123]

Clever use of a generator here. I like it.

Would prefer if someone who better understands the parsing requirements could also take a look though.

[Fishrock123]

CI: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/644/

[silverwind]

There're a few unused consts after this commit, probaby best to remove these (unless there's future use for them):

metaKeyCodeRe
functionKeyCodeRe
escapeCodeReAnywhere

[silverwind]

Tested it a bit. Escape sequences all work as expected, the code looks well documented, nice work!

[Fishrock123]

Does all the existing Buffer functionality still work?

[rlidwka]

No, it's not, and it didn't work before either.

I'd appreciate another look at this, but I think this Buffer handling was a dead code since this commit: 3c91a7a.

Function emitKeys never receives any buffers in the first place, because string_decoder.write() returns strings only.

[Fishrock123]

Ah true. Makes sense.

[Fishrock123]

LGTM, but maybe cc @piscisaureus?

[rlidwka]

There're a few unused consts after this commit, probaby best to remove these

Done. Some of rhe consts are used in stripVTControlCharacters below, so I removed other ones.

[Fishrock123]

should we put these into consts then? Does it make a difference?

[rlidwka]

Are you talking about regular expressions?

I think the only difference is readability, so if regexps are large enough, it'd make sense to move them out (or get rid of them since large regular expressions are a source of trouble usually).

But those are small, so they could be inlined.

V8 should create each regexp from regexp literal only once anyway.

[rlidwka]

Rebased on top of master branch and added generators to .eslintrc so it would lint successfully.

[silverwind]

LGTM

[silverwind]

Thanks! Landed in aed6bce