Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

readline: show completions only after 2nd TAB #7754

Closed
wants to merge 2 commits into from

Conversation

addaleax
Copy link
Member

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.

@addaleax addaleax added readline Issues and PRs related to the built-in readline module. semver-major PRs that contain breaking changes and should be released in the next major version. labels Jul 15, 2016
@Trott
Copy link
Member

Trott commented Jul 15, 2016

Code LGTM if CI is OK.

@addaleax
Copy link
Member Author

addaleax commented Jul 15, 2016

Thanks for the reminder. ;)

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

@trevnorris
Copy link
Contributor

LGTM


{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need { block } here ? Seems unnecessary

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@yorkie yorkie Aug 1, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const variables looks good to me, too :-)

@bnoordhuis
Copy link
Member

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.

@addaleax addaleax force-pushed the readline-tab-2nd-completion branch from 37229c6 to 8c35e25 Compare July 16, 2016 11:18
@jasnell
Copy link
Member

jasnell commented Aug 1, 2016

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.

@trevnorris trevnorris mentioned this pull request Aug 2, 2016
4 tasks
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: nodejs#7665
@addaleax addaleax force-pushed the readline-tab-2nd-completion branch from 8c35e25 to dca1f27 Compare August 2, 2016 16:30
}

// If there is a common prefix to all matches, then apply that portion.
const f = completions.filter(function(e) { if (e) return e; });
Copy link
Contributor

@princejwesley princejwesley Aug 2, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@princejwesley Done! :)

@jasnell
Copy link
Member

jasnell commented Aug 4, 2016

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

addaleax added a commit that referenced this pull request Aug 4, 2016
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
PR-URL: #7754
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
@addaleax
Copy link
Member Author

addaleax commented Aug 4, 2016

Landed in 1a9e247

@addaleax addaleax closed this Aug 4, 2016
@addaleax addaleax deleted the readline-tab-2nd-completion branch August 4, 2016 21:40
@gibfahn gibfahn mentioned this pull request Jun 15, 2017
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
readline Issues and PRs related to the built-in readline module. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[repl] do not show all matches on first tab
7 participants