Don't try to content assist in comments

[pspi]

Don't try to content assist / perform intellisense when writing a comment. Really really annoying, when every other word pops up suggestions. Don't want it.

Dupe of #538 that got closed but not fixed really though.

[felixfbecker]

Imo word suggestions are often quite helpful. For example when I make a comment like "this is later called by ..." and VS Code automatically suggests the long method name as I type.

[Kroc]

@fleixfbecker yes, but 'code' within comments should be escaped with backticks, the intellisense whilst writing comments is really slowing down my typing and interfering with expected spc/tab when writing prose.

[bpasero]

I am hitting an issue in comments that is ugly. My intent is to write this inside a TS/JS file:

/**
 * this is set.
 */

However set is a snippet and typing "." completes it so I end up with:

/**
 * this is 
 public set .(v : string) {
     this. = v;
 }

 */

Typing undo here I end up with:

/** */

@alexandrudima fyi about the undo behaviour here which is not very helpful.

[jrieken]

We should not add snippets inside comments, tho I am unsure if we know that when inserting them.

[alexdima]

@bpasero Pushed fix for undo behavior in 2cdf977

[bpasero]

@alexandrudima nice thanks!

[Kroc]

A set of 'scopes' / 'escapes' could be provided for comments, primarily that triple slash enables a 'line of code' within a comment, where intellisense could be available.

[jrieken]

yeah, #580 is about scopes et al - we don't have it yet in the ext host

[alexdima]

@jrieken Should we try to make the IntelliSense request pass in the scopes besides the position?

[jrieken]

That makes it related to #1172 which is about adding more contextual information to the provider. Two other options that I favour is either something like TextDocument.scopesAtPosition/Offset or the extend the document selector to know about scopes { language: 'javascript', scopes: 'comment.doc' }. The latter might be easiest to implement since it's evaluated on the main side

[andy-hanson]

It would also be nice to not have a leading * automatically added when I add a new line to a comment.

[jrieken]

@andy-hanson For jsdoc that should actually happen.

[felixfbecker]

@jrieken It does not for PHPDoc and I believe also not for JavaDoc.

[jrieken]

for sure not

[andy-hanson]

1. I am using typescript, but not jsdoc. Since jsdoc won't run on typescript files anyway, it's a strange assumption that any /** comments must be jsdoc.
2. typedoc does not require leading stars.
3. I tested on some js files and it looks like jsdoc does not require leading stars either.
   In general, I would like it to always be possible to get the editor to stop interfering, regardless of the tools or coding styles it thinks I should be using.

[roslanr18]

Pada 19/01/2016 1:22 PG, "Andy Hanson" notifications@github.com menulis:

1. I am using typescript, but not jsdoc. Since jsdoc won't run on
   typescript files anyway, it's a strange assumption that any /** comments
   must be jsdoc.
2. typedoc https://github.com/sebastian-lenz/typedoc does not require
   leading stars.
3. I tested on some js files and it looks like jsdoc does not require
   leading stars either.
   In general, I would like it to always be possible to get the editor to
   stop interfering, regardless of the tools or coding styles it thinks I
   should be using.

—
Reply to this email directly or view it on GitHub
#1657 (comment).

[hoovercj]

From #580 (comment)

From @egamma on November 2, 2015 8:16
Exposing the scope names in the API is on the backlog, but will not make it into the November update.

I would like TextDocument.scopesAtPosition/Offset, or something along the lines of the atom api

[jrieken]

I think the real issue is that 24x7 IntelliSense shouldn't be active in all cases, esp when a 'smart' completion provider is there but didn't produce a result. In such cases the textual provider should only become active if explicitly invoked (Cmd+Space).

[egamma]

👍 and this should be the default behaviour.

We could still provide a setting 'always include textual completions' for users that like the current behaviour.

[jrieken]

agreed

[jrieken]

An alternative idea is to configure what Enter should do when completions are shown. We could add an option to accept a completion on Tab only (ala editor.acceptSuggestionOnEnter: false). That's helps us to know what the user actually wants. In addition, we can add Shift+Enter to accept a completion and Shift+Tab to insert a tab (when completions are shown).

[csholmq]

@jrieken 👍 on the editor.acceptSuggestionOnEnter: false.

[lukehoban]

@jrieken So was the decision not to do this:

I think the real issue is that 24x7 IntelliSense shouldn't be active in all cases, esp when a 'smart' completion provider is there but didn't produce a result. In such cases the textual provider should only become active if explicitly invoked (Cmd+Space).

👍 and this should be the default behaviour. We could still provide a setting 'always include textual completions' for users that like the current behaviour.

For the Go plugin, I know there are a number of users who would have liked that default behaviour (not showing completion lists with textual completion and snippets automatically when the Go completion provider has returned no results, only on cmd+space).

The editor.acceptSuggestionOnEnter approach seems like it won't fix the default experience, and turning this option on will degrade the experience in normal completion outside of the undesirable locations like comments and strings.

It seems like the ultimate fix here is addressing a different problem than the core concern. The suggestion you proposed in the quote above seems to fix the core concern.

[jrieken]

We made this decision basically because we don't want to step onto the toes of those that actually like textual completions everywhere. Also it wouldn't have helped in cases in which only textual completions are available, esp in markdown files. Last, it's aligned with what other editors do, so with muscle memory of those users.

[alexdima]

Verified setting editor.acceptSuggestionOnEnter to false no longer makes Enter and accept key for suggestions

[natefinch]

FWIW, I also find this to be super annoying. I've never seen another editor suggest random words from the file when typing comments. It's distracting and unhelpful. I'm fine with having to set a value to turn it off, but please give me that ability... and I mean turning off suggestions in comments entirely.

I'm not sure why this issue is marked as closed... unless I'm missing something, there's been no proposed workaround for the problem of showing suggestions, only for turning off autocomplete on enter, which is more of a symptom than the actual disease.

[alexturek]

Searching for turn off suggestion in text files vscode I get to #3137 which is closed as a dupe of #2496 which is closed as a dupe of this issue which... doesn't help me disable suggestions in a specific file format.

Has anyone actually solved this, or did that issue get conflated with the ability to completely disable intellisense? The docs suggest it's still not possible to disable by file format.

[jimfoye]

When I hit the enter key to start a new line in a comment, the editor often "helpfully" completes my sentence with something I don't want. I don't think I could put it any better than @natefinch did above. This is really annoying!

[jtzeng]

Ah that's a shame. Guess I just have to disable it manually. :(

[DarrenCook]

Could someone, who knows the code, suggest where a patch would go, and how it might work?

I guess we need a boolean function that will ask isCursorInsideAComment(), or getCursorContext() might be better, so we can distinguish between single-line comments, block comments, and javadoc comments (start with /**).

And then use that function (*) at the point where it decides if to show intellisense suggestions or not. I think the answer to the latter might be related to #1172 ?
*: based on a user setting, of course, so people who want to write code inside comments still can.

[JesperTreetop]

Per the other comments, please reopen this or allow one of the "dupe" issues to be opened for the benefit of those of us who don't want random word autocomplete when editing text files. Since editing Markdown files is one of the intended uses of Visual Studio Code to the extent that it gets special features like live preview, I think this deserves not to be clumped together with disabling autocomplete within comments (which is probably still a good idea).

[JesperTreetop]

For those that don't want to see word-based suggestion for certain languages you can say "[markdown]": { "editor.wordBasedSuggestions": false } (available in insiders today or the January release).

This is spectacular, since it was something that wasn't possible yet earlier in the thread. Awaiting the January release with bated breath. 😄

[jrieken]

re #1657 (comment): Sorry, I deleted my comment because it contained a link to the wrong issue 🙃

So, this is what I have suggested in #10819 (comment):

"editor.wordBasedCompletion": true,
"[markdown]": {
  "editor.wordBasedCompletion": false
}

[jrieken]

I have also reopened this issue for the following change: In addition to the plain boolean that editor.wordBasedCompletion accepts today I want to extend it to something that allows to say word based suggestion 'in comment only', 'in string only', 'nowhere' etc. Samples:

// nowhere
"editor.wordBasedCompletion": false,

// everywhere
"editor.wordBasedCompletion": true,

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

[alexturek]

Hey, thank you to whoever added file-type specific editor settings. Now.. can we get all file types, and not just the four that exist? I'd be happy to open a PR if someone could point me to the right area.

I'm not sure why these were the only languages that made the cut :)

EDIT: Spoke too soon!

For anyone else who finds this issue:

1. Go to language-specific settings (cmd + shift + P)

2. This will insert the correct language settings override in your settings.json, which you can then edit

[jrieken]

The additional configuration options for word-based suggestion are now tracked in #9504 and are plan for March. Closing this issue as the remaining work will happen there. Happy Coding!