readline: show completions only after 2nd TAB

[addaleax]

Checklist

• make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

readline

Description of change

Show TAB completion suggestions only after the user has pressed TAB twice in a row, so that the full list of suggestions doesn’t present a distraction. The first time a TAB key is pressed, only partial longest-common-prefix completion is performed.

This moves the readline autocompletion a lot closer to what e.g. bash does.

Fixes: #7665

This is arguably an exclusively human-facing part of the readline functionality, so the semver-major label is up for debate.

[Trott]

Code LGTM if CI is OK.

[addaleax]

Thanks for the reminder. ;)

CI: https://ci.nodejs.org/job/node-test-commit/4129/ (edit: It’s green.)

[trevnorris]

LGTM

[princejwesley]

Do we need { block } here ? Seems unnecessary

[addaleax]

It’s just to keep the diff small, I don’t feel strongly about it.

[yorkie]

@princejwesley @addaleax I think using let on the following 2 line could make the block start scoping there.

[addaleax]

@yorkie Sorry, I’m not entirely sure what you’re suggesting – would you like to see the block removed? let vs var shouldn’t matter (but I would change var -> let if the block is removed, yes)

[yorkie]

let vs var shouldn’t matter

I don't think so because here the brackets would create a scope with let declaration but not for var. For example:

{
  var f = completions.filter(function(e) { if (e) return e; });
  var prefix = commonPrefix(f);
}
// here we actually can access `f` and `prefix`, this is not what we expect by brackets.
// using `let` instead of `var` can make it expected result.

Actually my suggestion is not removing brackets here and changing var -> let.

[trevnorris]

any performance difference between let vs var is measured in nanoseconds (approaching a microsecond in one really strange past case, but has been fixed), and either way shouldn't be a consideration for this PR.

[yorkie]

So I think here using let with block would reduce the possibility to produce bugs, because the variables are isolated to top scope.

[trevnorris]

To summarize, if we use var then remove the block scope. If we keep the block scope then switch to let. Personally I don't care either way. @addaleax Let's do one or the other, but I'll leave that up to you.

[addaleax]

I’ve removed the extra block scope here and const’ed the variables, that should be okay (but if anyone wants something else very strongly, I’ll change that again. I don’t really care that much either).

[yorkie]

const variables looks good to me, too :-)

[bnoordhuis]

LGTM

As to semver-minor vs. semver-major, this change could conceivably break scripted uses of the readline module.

I don't know if anyone actually does that (besides us, in our test suite) but I'd err on the side of caution.

[jasnell]

This LGTM. One thing we may want to consider as a follow on for this is to put some kind of time-limit for the second TAB press... that may be overkill tho.

[princejwesley]

@addaleax
we don't need to run this block of code when completions.length === 1, right?
I mean, self._insertString(completions[0].slice(completeOn.length)) is sufficient.

[addaleax]

@princejwesley Yeah… I’m not sure if that’s worth it, at least for tab completion. ;) If you want, I can add a strings.length === 1 shortcut case to commonPrefix(), that’s probably where most of the unnecessary work would happen otherwise?

[princejwesley]

@addaleax Yes. Its good to add length check in commonPrefix().

[addaleax]

@princejwesley Done! :)

[jasnell]

Still LGTM!
New CI: https://ci.nodejs.org/job/node-test-pull-request/3527/

[addaleax]

Landed in 1a9e247