Autocomplete annoyingly tries to complete in comments.

[JapanIsShinto]

• VSCode Version: 1.3.1
• OS Version: not likely relevant, but it's Windows 7

I'm new to Visual Studio Code, so be gentle. There is new behavior in VSCode (or at least I don't remember it in the past). I don't know if it's part of the base VSCode, part of Microsoft's C/C++ extension that I installed, or some combination of both. But the end effect is that when I'm typing in a comment (either // or /* */ style), the autocomplete popup decides to show itself when it sees text that it knows. An example:

1. Type "// This isn't fun"
2. Autocomplete will now popup, offering to complete "fun".
3. The word I wanted was indeed fun, so I type space.
4. Autocomplete changes "fun " to "function" for me.
5. Now I have to go back and edit it.

Similar things happen when I'm typing a period to end a sentence. Autocomplete sees this as an opportunity to try to turn a simple period into a dereference to a member.

The issue is that while having autocomplete do this on code is exactly what I want, having it do this when I'm typing comments is exactly what I don't.

[kieferrm]

@JapanIsShinto I can't reproduce the behavior you describe in the current insider build 1.4.0 or the last stable 1.3.1. with or without the C++ extension installed. Completion proposals are inserted on Tab and Enter but not on Space. Do you see the behavior in other file types such as javascript or json? If yes, can you please run vscode without extensions using the --disable-extensions command line argument and see if that makes a difference?

[JapanIsShinto]

I was convinced that it was completing words on space, but now I can't reproduce that either. I'll go back and try to figure out why I thought that was the case. But I can say this-- autocomplete often doesn't do what I want when editing comments. Take for example a struct Foo that has a member Bar. This I can reproduce:

// update Foo.

At the point I type the period, I am given possible completions. I then type return because it's the end of the line and autocomplete types this for me:

// update Foo.bar

And then I have to go back and fix it.

As my comments are likely to reference symbols in my code, this happens more often than I like. I guess what would be ideal would be that autocomplete would have some minor syntax awareness so that when in comments, completions would by default be turned off. Looking at the key bindings, it looks like Ctrl-Space ("Trigger Suggest") can manually activate it if needed in comments.

[ghost]

What's happening (for me at least) is that autocomplete is popping up at the end of a line. So (as in @JapanIsShinto's example) if you type "fun" and autocomplete pops up suggesting "function" and you press return to start a new line... and "function" is entered into the comment.

This is /really/ annoying and happens with unbearable frequency.

Please fix it. :-(

Version info:

Version 1.3.1
Commit e6b4afa
Date 2016-07-12T13:28:46.761Z
Shell 0.37.6
Renderer 49.0.2623.75
Node 5.10.0

[jrieken]

There are two setting to control this: "editor.wordBasedSuggestions": true | false and "editor.acceptSuggestionOnEnter": true | false. The former will not provide suggestions that are just word based (often known as stupid) effectively not producing suggestions in comments, the latter resolves the conflict between inserting a newline and accepting a suggestion.

[JapanIsShinto]

I'm not sure what happens when I add a comment on a closed issue. Let's find out.

Thanks for the two settings changes. I haven't tried them yet, but it sounds like it will work. The only comment I'd add is that I've never changed the settings, so these are defaults. Microsoft should probably consider changing these defaults, because I can't imagine the situation where the current behavior is something actually desired.

[ghost]

So I can't use word based suggestions and accept-suggestion-on-enter in code just to fix this dodgy behaviour in comments? Doesn't seem like a fix to me.

I want to hit enter to accept autocomplete suggestions and I'd like word based suggestions too please. Just not in comments...

[pfurini]

Totally agree with @oheard, this is a really odd behavior, no other editor works like vscode when writing comments, and I used a lot of them..
Please don't keep closing issues on this pointing out that two settings, because it's not what your users want. They want a proper fix.

[nkoren]

Just came here to add a "me too". VS Code is a wonderful editor, except for writing comments where it is just appalling. It's gotten to the point where if I'm writing more than a one-line comment block, I'll do it in another text editor and then copy that into VS Code, just to avoid all the hassle with autocomplete in comments. Really there needs to be a means of disabling autocomplete in comments, and this needs to be default behaviour.

[podom]

Old thread, but I would to also point out Code's annoying and related behavior of doing block completion in C/C++ comments. For example, if I type any word with an apostrophe in it ("can't", "it's") inside a comment, I get a second apostrophe that I have to delete.

I had to set "editor.autoClosingBrackets" to false to get rid of this behavior, which is normally quite useful. There needs to be some awareness that comments aren't code.

[SyntaxErrorOnLine1]

Not sure why this issue is closed, as it's ongoing in VS Code 1.9.1. And I would guess it affects any/most languages. I'm writing Typescript and frequently have to go back and fix my comments after VS Code decides to autocomplete them. Really infuriating.

Yes, there's a fix above, but do I have to lose these features outside of comments where they're useful, just to get "standard" editor behavior in the comments?

Issue should be re-opened as it needs fixing.

[egamma]

Reopening this issue, we want to revisit this in March.

[jrieken]

We have now the needed details available that allow us to offer more fine grained control over this. The idea is that we add more config, like 'never complete with words', 'never complete with words in strings', 'never complete with words in comments'

[jrieken]

Proposal form #1657 (comment)

// nowhere
"editor.wordBasedCompletion": false,

// everywhere
"editor.wordBasedCompletion": true,

// somewhere
"editor.wordBasedCompletion": {
  "inStrings": true,
  "inComment": false,
  "inCode": true
}

[jrieken]

an alternative to #9504 (comment) could be to not use a object but a value set

// nowhere
"editor.wordBasedCompletion": false,

// everywhere
"editor.wordBasedCompletion": true,

// somewhere
"editor.wordBasedCompletion": ["inStrings", "inCode"],

or the use of different individual settings, like

"editor.suggestWordsInComments": false,
"editor.suggestWordsInStrings": true,
"editor.suggestWordsInCode": true

The latter is a completely new system. Questionable if suggestWords is a good phrase or if it should be wordBasedCompletionsInXYZ. Also questionable if InCode is good because for language like markdown or plaintext it's always code-tokens but actually not code...

@aeschli @sandy081 masters of settings and json. preferences or suggestions?

[jrieken]

or (last proposal 🤞 )

// complete with words unless when inside a string
"editor.wordBasedCompletion": true,
"editor.wordBasedCompletionInComments": false,
"editor.wordBasedCompletionInStrings": true,

[jrieken]

@aeschli Maybe not default but other?

[DarrenCook]

As this has been closed, does this mean it will be available in the next nightly build ("Insiders release"), and I can finally switch off auto-complete in comments and strings? If so, thanks for the hard work!

(If not, and this issue was just about the settings control for it, could you link to the issue I need to be following for the implementation? Thanks!)

[jrieken]

@DarrenCook psst, already today can add this to your settings.json file: "editor.wordBasedSuggestions": {"comments": false}, The last commits were just to rename default to other and make the default be only in other (not strings, not comments by default)

[DarrenCook]

Thanks - it works. Can I suggest the default be changed from true to:

"editor.wordBasedSuggestions": {
    "comments":false,
    "strings":false,
   "default": true

},

(or all true, if backwards compatibility is essential). Mainly so that people know the settings are there, and won't keep opening issues about it ;-)

(I thought that was what one of the above commits was about, but I think that only affects what happens if you specify "editor.wordBasedSuggestions": {} ? I'm using the Insiders version downloaded about 30 mins ago, by the way.)

I also had to do:

"editor.snippetSuggestions": "none",

Because snippets still work in comments/strings. They were less noisy, but I personally never use them anyway, so that fix is good enough.

[jrieken]

9965a5d did make the default {comments: false, strings: false, default: true} but if you have the setting already customised (true or false) we will still honour that. Remove it, and configure it again and you'll see the new defaults.

[jrieken]

Snippets in strings and comments is good feedback. Idea is to allow snippets to tell in what scopes they wanna be active.

[jrieken]

I have extracted #9504 (comment) to #22661

[jrieken]

Reopening this because this isn't just a problem with word-based (aka stupid) completions but with completions inside comments in general, esp or only when showing as you type (aka 24x7 IntelliSense, quick-suggestions). Instead (or in addition) to configuring word-based completions we should make the quick-suggest behaviour dependent on the scope (comment, string, other)

[jrieken]

Ok. I have reverted the editor.wordBasedSuggestions-setting to be true or false and made the editor.quickSuggestions-setting more rich such that you define the scopes, like so

	"editor.quickSuggestions": {
		"other": true,
		"comments": false,
		"strings": false
	}

This means suggestions (from any provider, including snippets) are still available in comments and strings, but only when explicitly requested either via Ctrl+Space or when typing a trigger-character but not in the 24x7 manner, not showing suggestions as you type. This should make it a lot less annoying and allows pressing enter in a comment without accidentally selecting a more or less random suggestion

[elirnm]

Are periods considered a trigger character? Because if they are then there's still an issue with hitting enter after ending a sentence in a comment.

[jrieken]

Are periods considered a trigger character? Because if they are then there's still an issue with hitting enter after ending a sentence in a comment.

They are but only ask those providers that contributed them, mainly smart providers like TypeScript, C#, and they will not produce a result so it shouldn't be a problem

[DonJayamanne]

@jrieken
What do i need to do to ensure code completion is not enabled for python code within comments and strings when entering a period?

[jrieken]

If you register yourself as a completion item provider on characters like . we assume that you backend is able to figure out if a position is inside a string or comment. In that case your provider should return null, undefined, or an empty result.

[nathj07]

An interesting find using:

"editor.quickSuggestions": {
    "other": true,
    "comments": false,
    "strings": false
  }

In a Go file this works with single line comments; hitting '.' does not pop up the options box. However, in a multi-line comment the '.' still triggers the box.
I'm using vscode 1.12.2. Is there any news on extending the before to work in multi-line comments?

[jrieken]

cc @ramya-rao-a for go completing in multiline comments. The setting is only about quick suggestions, not trigger characters. When invoked a completion item provider should always check if it makes sense to complete at that code location