dotnet / vscode-csharp

Official C# support for Visual Studio Code
MIT License
2.85k stars 668 forks source link

Suggestions in comments on trigger characters despite setting #1424

Open jrieken opened 7 years ago

jrieken commented 7 years ago

From @Dima4ka on April 21, 2017 1:44

Steps to Reproduce:

  1. Install C# extension
  2. Set:
"editor.quickSuggestions": {
    "other": true,
    "comments": false,
    "strings": false
  },
  1. In .cs file write a block comment like this:
/// <summary
/// Checks that Index method returns proper model and status codes.
/// </summary>
  1. Put dot in comment (at the end)

Expected

Nothing shows up

Actual

Silly suggestion (!--) shows up

Copied from original issue: Microsoft/vscode#25109

jrieken commented 7 years ago

From @mjbvz on April 21, 2017 2:5

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

jrieken commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago
screen shot 2017-04-24 at 08 51 46

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

jrieken commented 7 years ago

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 commented 7 years ago

Yeah, this has come up before (https://github.com/Microsoft/vscode/issues/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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

winzig commented 6 years ago

This issue drives me insane on an hourly basis. 🤪

I've found dozens of issues that reference this problem, so it's not clear to me, is this issue (#1424) supposed to be the place to track this problem, or has it moved to another issue somewhere else?

Trying to find out what the hold up is in fixing this. Can't figure out how this isn't driving enough people crazy to move it to a higher priority... is my configuration bad, or is no one else using punctuation in their code comments? 😂

jkyeung commented 6 years ago

@winzig - The hold-up might be that the issue isn't really related to OmniSharp, but rather VS Code itself. It used to drive me crazy (editing Python code; I've never installed OmniSharp) but I wound up just turning off all trigger character suggestions (see my previous comment).

winzig commented 6 years ago

@jkyeung Thanks, I did notice your comment after I posted (of course). It definitely helps with the primary issue I'm facing, but now it highlights another problem – my memory of the c# language is apparently worse than I expected. ;-)

In other words, I apparently rely on hitting "." to see what methods are available for a given type quite often. Hopefully this issue can be resolved somewhere soon. 🤣

lonix1 commented 5 years ago

The vscode team doesn't believe it's their fault - so where does the problem lie?

This drives me crazy every day. I'm glad I'm not alone :)

Does someone know which workaround has less side-effects for now:

"editor.acceptSuggestionOnCommitCharacter": false,

or

"editor.suggestOnTriggerCharacters": false
SeijiSuenaga commented 5 years ago

Based on the discussion above, it sounds like this extension doesn't receive enough contextual information from omnisharp-roslyn to fix the problem.

rusmaxham commented 5 years ago

This issue also drives me nuts.

samprakos commented 3 years ago

Is this on the roadmap? It's insane...I love VS Code but I can't write comments without stumbling all over myself trying to avoid intellisense when I type a period at the end of my carefully crafted sentences :)

KillyMXI commented 3 years ago

Hmm. I don't have OmniSharp installed and got a similar issue with a different extension: https://github.com/SamVerschueren/vscode-ava/issues/9

That one might be more distilled example. It seems more likely to me that it is actually a vscode bug after all.