Vscode: Autocomplete is inserting selection after typing period

Created on 10 Mar 2019  路  20Comments  路  Source: microsoft/vscode

Justification

This is a duplicate of #47696 which IMHO was closed prematurely. There seems to be confusion between a hotkey which launches intellisense (like .) and a hotkey which confirms the intellisense suggestion (like <tab> or <enter>. Normally, when one types . one expects suggestions but does NOT want the first suggestion to be accepted. If I type window. I do not want window.location because location is at the top of the list. . is not, a "commit character" as mjbvz says - rather it should offer suggestions but not choose them.

If we're agreed on that then there does seem to be a bug:

  • OCCASIONALLY when I type dp( I get devicePixelRatio inserted which is not what I want.
  • OCCASIONALLY, when I type steps I get SVGTextPositioningElement.

I can't reproduce it always but it happens sometimes and seems to be design according to #47696. That cannot be right.

  • VSCode Version: 1.32.1 (user)
  • OS Version: Windows 10

Original Bug Report

Autocomplete is inserting the selected suggestion after the user types a period. This is not mentioned in the User Guide, which says Pressing Tab or Enter will insert the selected member., and there appears to me to be no clear way to disable this via the keymap. I suspect this is a behavior that some users may expect, but it would be nice if there was some way to disable it, as it makes for a frustrating experience to type out property names that Intellisense is not suggesting.

  • VSCode Version: 1.22.1
  • OS Version: macOS 10.13.1
  • Does this issue occur when all extensions are disabled?: Yes

Steps to Reproduce:

Create a Javascript file test.js

  1. Type window
  2. Type .
  3. Because the first suggestion is addEventListener, the result will be window.addEventListener.
needs more info

Most helpful comment

I hate this behaviour. I have added "editor.acceptSuggestionOnCommitCharacter": false to my settings.json.

It just feels so unnatural otherwise. If I want something to auto-complete I will press tab, otherwise it should never auto-complete. I don't understand why this isn't the default behaviour.

All 20 comments

What you described is the expected behavior of commit characters: they accept the currently showing suggestion. We treat . as a commit character in js/ts. You can press esc to cancel out of suggestion if you don't want to accept the current suggestion when typing a commit character, or disable commit characters by setting "editor.acceptSuggestionOnCommitCharacter": false

I can't reproduce addEventListener being the first suggestion after typing window. Are you typing . twice in that example? Or do you have an extension installed that could be adding additional suggestions?

Looks similar to #66868

There are multiple reports, and I can also reproduce it with latest insiders build.

1

Yes, you have to type very fast, or make your computer run slower may help reproduce.

It's also very funny that different type speed will give me different suggestions.

2

When I type "T H" very fast, it gives me UNSAFE_componentWillMount, which is a reproduce of #66868.

But when I type slowly, it gives me containerRef, as the above comment shows.

We treat . as a commit character in js/ts.

So you want window. to resolve to window.location immediately on pressing .?? I must be misunderstanding you, that can't be how you work. Indeed, that isn't how it works most of the time nor in any other IDE or source code editor. . is a typical "propose" not "commit" character.

I think @yume-chan is on the right track: when typing fast it happens, otherwise it doesn't.

I hate this behaviour. I have added "editor.acceptSuggestionOnCommitCharacter": false to my settings.json.

It just feels so unnatural otherwise. If I want something to auto-complete I will press tab, otherwise it should never auto-complete. I don't understand why this isn't the default behaviour.

I'm getting this as well. It's maddening --- I keep getting spurious and incorrect insertion of text. I've seen it happen on commas, spaces and various other bits of punctuation, too. I know that some people like it, but I would really like a way to disable it completely (except for tab, of course).

Just had it again: typing at speed and hit dp( and suddenly I had devicePixelRatio appear. @yume-chan has nailed it - it's a speed bug.

@cawoodm I don't think it's a speed bug. If you type dp and then wait a while and then type ( it will still complete with devicePixelRatio. No?

It does in my build, I just tested it. I'm using VS Code 1.31.1

@yume-chan I believe your observation is not related to this issue. This issue relates to accepting autocomplete suggestions and how annoying it is that period and also bracket are treated as "commit characters". The behaviour you describe is related to the population/generation of the autocomplete suggestions and not the accepting of the suggestion.

@davidgiven You can disable it (except for tab, of course :P). Open your settings.json and add "editor.acceptSuggestionOnCommitCharacter": false

I am still confused why this isn't the default setting though. Or why there are "commit characters" other than tab.

What you described is the expected behavior of commit characters: they accept the currently showing suggestion. We treat . as a commit character in js/ts. You can press esc to cancel out of suggestion if you don't want to accept the current suggestion when typing a commit character, or disable commit characters by setting "editor.acceptSuggestionOnCommitCharacter": false

I can't reproduce addEventListener being the first suggestion after typing window. Are you typing . twice in that example? Or do you have an extension installed that could be adding additional suggestions?

@mjbvz This drives me mad 馃槅 . I do test-driven development and the majority of the time I am writing the code as I expect it to be used before actually implementing it. So period and parentheses as commit characters always ends up producing an incorrect autocomplete. It's very annoying to have to press ESC every time I dot into something or call a method that autocomplete hasn't found (because it doesn't exist yet).

I think we have to say that ( and . CAN be a commit character if we're actually inside an object so object.method( may autocomplete on the ( but not on the . for the simple reason that I may have an object which VSCode does not know and VSCode should not change it into objectWhichVSCodeDoesknow.

So if I type dp( there is NO REASON IN THE WORLD to replace this with devicePixelRatio.

If I type object. there is no reason to autocomplete this to objectWhichVSCodeKnowsButIDontWant.

I think by only autocompleting actual members instead of top level objects we would be rid of this bug.

Does anyone seriously want win. to become window.. Are they a majority?

Been getting this consistently in a React class-based component where you starting typing this. quickly, and it auto completes to this.UNSAFE_componentWillMount. I disabled "editor.acceptSuggestionOnCommitCharacter" which does resolve the issue but it sort of just patches the problem.

Another similar issue that was closed prematurely is #56026

+1 to the issue. experiencing it all the time. very annoying.

@ivanvoznyakovsky and @prurph please add your thumbs up to the issue description.

I've noticed for a while now that, occasionally, when I type this., VSCode would autocomplete to something unexpected.

I just updated to the latest release and created a new test file. In the new file, I could not type it(, because pressing the ( character autocompleted to italics( as well as imported the function from somewhere. I switched off auto imports and tried again and it would autocomplete to instanceof(. There was no way at all for me to type it( until I disabled acceptSuggestionOnCommitCharacter in my settings.json.

That this is the default behaviour is absolute madness.

I keep experiencing aggressive autocomplete suggestions in JavaScript environments when trying to type three dots for, say, spreading or rest props. The autocomplete has always been excellent, but a recent change must have introduced some kind of regression.

It only happens sometimes, and it often occurs in situations where it doesn't make sense. For instance, if I try to type:

const { ...rest } = something;

it would end up becoming:

const { .children

once I type the second .

Actual screenshot from VSCode showing the bug (this one occurred on the third period):

image

For now, I've disabled this setting by disabling acceptSuggestionOnCommitCharacter (thanks, earlier posters), but I'd love to re-enable it if it could be made a bit smarter!

I captured a gif of me typing in a python environment fig = plt.figure('dwa')<enter> which get replaced by fig = plt because the period is ignored by the autocomplete window:

EDIT: a blank javascript or python buffer does not appear to exhibit this behavior. Autocomplete in a small file does not seem to behave this way either. It sometimes happen that there is a lag between the typing of the dot . and the update of the suggestion window. Sometimes however with the same vscode window, I cannot get the . character to commit the suggestion at all no matter how long I wait.

@Hiestaa Please file that issue against the python extension

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

I think this bug should remain open, as it is still affecting multiple users.

Was this page helpful?
0 / 5 - 0 ratings