Suggestions in comments on trigger characters despite setting

[jrieken]

From @Dima4ka on April 21, 2017 1:44

• VSCode Version: 1.11.2
• OS Version: macOS 10.12.4

Steps to Reproduce:

1. Install C# extension
2. Set:

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

3. In .cs file write a block comment like this:

/// <summary
/// Checks that Index method returns proper model and status codes.
/// </summary>

4. Put dot in comment (at the end)

Expected

Nothing shows up

Actual

Silly suggestion (!--) shows up

Copied from original issue: microsoft/vscode#25109

[jrieken]

From @mjbvz on April 21, 2017 2:5

Thanks @Dima4ka! I believe that I was also able to reproduce this issue in TypeScript

[jrieken]

Yes. That is the design because trigger characters still have a purpose there, think of @ completions for doc comments as in /** @param <suggests foo-param>. Unsure what !-- is but my guess is that it's a snippet, right @Dima4ka ?

[jrieken]

From @Dima4ka on April 21, 2017 21:48

@jrieken No, it was not snippet, it is rather "abc" guess (not intelligent). Looks like part of the HML comment <!-- comment -->. Anyway, although I appreciate Intellisence in comments, it is annoying when I type a line of text, hit dot to complete my sentence, hit Enter to move to the new line and it turns out that I have typed random piece of text.

. is supposed to help with class methods and properties mostly. Maybe it would make sense to have different "trigger characters" for comments and code.

[jrieken]

No 'ABC' icon for me, but the keyword icon. My guess is that this is coming from the C# extension. @DustinCampbell Ideas?

[jrieken]

From @DustinCampbell on April 24, 2017 13:22

Note that in C#, XML documentation comments aren't precisely "comments". They're very special. Also, in the example, the <summary> isn't closed, so in a sense, you're tying in a tag and not in the comment itself, which is why these keywords would be suggested (contextually). That said, it's clearly a bug that typing a period makes completion appear here. That shouldn't happen. This bug should probably be moved to omnisharp-vscode.

@jrieken, we're starting to get into territory that it is pretty tricky to get make correct for C# without a little help from VS Code's completion API to let us know how completion was triggered. C# completion can do different things depending on what the user did. Knowing whether the user triggered completion by typing the last character that appears in the document or whether they typing Ctrl+Space can be important.

[jrieken]

Yeah, this has come up before (microsoft/vscode#752) but hasn't been tackled yet. It's a little harder to do without breaking the API because we want to keep the rule "CancellationToken comes last"...

I'll move the issue to vscode-omnisharp to begin with ;-)

[TheRealPiotrP]

@DustinCampbell I spent some time with @akshita31 today getting familiar with this issue and the associated code paths. What were your thoughts for a fix? You mentioned above that this issue should live in omnisharp-vscode but I'm not convinced we have enough context until the request makes it to omnisharp-roslyn.

The CompletionTriggerKind property on the CompletionContext already tells us if the completion was caused by a trigger character or by direct invocation. However, I think we want the trigger character to be available outside of string literals/comments and only disabled in those contexts. To achieve this, I think we need to have Omnisharp-Roslyn build an AST and understand the context in which the trigger character was pressed. But there must be an easier way...

[DustinCampbell]

I honestly think this is probably just an issue in omnisharp-roslyn. It would likely just go away once we get the PRs in that just use Roslyn's completion API directly.

[jkyeung]

I don't think it's an OmniSharp issue. I get it in Python as well. Even in this very thread, it was mentioned that it happens in TypeScript also. People end sentences with periods in comments. It's that simple. Even "special" comments like docstrings or anything else you care to think of. In any context where people are allowed to enter regular sentences in plain text, people are going to end those sentences with periods.

I liked the suggestion to make the trigger characters different in different contexts. (Question: Is there a way to know what the trigger characters are, short of experimentation? I mean, other than periods, of course. Are they language-specific?)

FWIW, the trigger-character suggestions do not show up for me in strings, no matter what I specify in editor.quickSuggestions (but the type-a-few-characters-first suggestions are controlled by that setting). Trigger-character suggestions always show up in "other", like they do in comments, regardless of editor.quickSuggestions.

Fortunately, we can get a little peace and quiet with "editor.suggestOnTriggerCharacters": false. (But again, I'd really like to know what the trigger characters are, and if possible, just stop the suggestions for periods, potentially keeping them for other trigger characters.)