Like editor.formatOnSave, editor.suggest.snippetsPreventQuickSuggestions is owned and used by the vscode, so this extension has no control over how this setting is used, other than suggesting the best setting for Go development using configurationDefaults which is what the change for #839 did.

Please override the Go-specific setting by using

"[go]": {
   "editor.suggest.snippetsPreventQUickSuggestsions": false
 }  

In the mean time, how about upvoting microsoft/vscode#58995 to make this language-specific setting default more visible to users?

This bug probably failed to describe the real issue. Let me add some context.

My personal experience was that snippets suddenly started expanding stuff when while tabbing between fields. I had never seen this behaviour before. I assumed it to be a bug.

After months of mild frustration I realised that the "bug" was not being addressed, so I started googling for answers. I found the setting editor.suggest.snippetsPreventQuickSuggestions, and that it can be toggled on/off in the settings. Toggling the setting did not affect the behaviour, which confirmed my hypothesis that it was a bug.

I tried other languages to locate the bug, and I noticed that only Go had it. I dissected VSCode versions until I found the breaking release. That's when I found #839.

If you set up projects in Rust, JS, Python, C# and Go, then the only language that behaves in this manner is Go.

No matter how many people would've preferred this setting to diverge from the global default, I still do not think that such changes are warranted.

And even if an extension's custom default values were more visible in the settings UI, it would not have helped. This was so orthogonal with my usual experience in VSCode that it never once crossed my mind that Go might have custom default values.

I highly suggest that this change is reverted so that the default value is aligned with the global default.

Here's some more reasoning in case it helps make my case.

For all (boolean) preferences in VSCode, there are two types of people: those who prefer it on, and those who prefer it off. When the default value aligns with a person's preference - things just happen to work out of the box.

For those who prefer it the other way, if the setting is important / annoying enough, they might Google their way to the setting's name and find out how it can be changed. This is what happened in #839 .

When the default value of a toggle is flipped, all users who had never known about the setting are forced to learn about it. On top of that, in this scenario those users also have to somehow know to search for the Go issue tracker to find out that Go's values diverge from the rest of the VSCode ecosystem.

Another side-effect of having a Go-specific default is that any user who uses snippets in Go and another language would by necessity have to learn about this setting.

I hope that you see my point here. It is applicable to not only this setting but the vast majority of preferences. It is also independent of how many think that setting should have a certain default or not - a global "bad" consistent behaviour is better than inconsistent "sometimes good" behaviour.

@sebnyberg I am sorry for your frustration, and thanks for sharing your thought. We changed the default after observing many users who struggled with completion behavior and thinking about it for months. We don't take the default change lightly.

As discussed in microsoft/vscode#5844 and eventually in microsoft/vscode#58995, surfacing this language-specific change better in VS Code UI could help users who use snippets and know about this setting understand what is going on immediately. Once the language specific defaults are understood, this becomes the "consistent" behavior.

#839 landed in many months ago. Changes in other settings were many years old. Reverting them now would affect many more users. Instead, we will look for a way to improve the visibility from the extension side.

Thanks for reporting the issue - I hope users like you now might google their way and find the culprit easily through this issue.

[...] We changed the default after observing many users who struggled with completion behavior and thinking about it for months. We don't take the default change lightly.

I don't agree with this. The group that you saw struggling with this behaviour is simply the set of users who don't agree with the default behaviour in VSCode. That does not imply that the default value should change. It's just a matter of those people learning about the setting and and how to change it. Also, there is a bias to an issue like #839 - anyone who likes the VSCode default would never even visit the issue - they don't even know that the setting exists.

As discussed in microsoft/vscode#5844 and eventually in microsoft/vscode#58995, surfacing this language-specific change better in VS Code UI could help users who use snippets and know about this setting understand what is going on immediately.

I don't think this addresses the issue. I can't say that I represent the average VSCode user, but I have never used the settings UI. Many users come from a background where settings are managed in settings files (e.g. Vim, Emacs) and they would not think to look in the UI.

Here goes another attempt at showing why having a different default in a language than the global default is a poor choice.

First, let's all agree that most users don't want to know what settings are called or how they work. They want VSCode to magically work exactly like they want it to, out of the box. So forcing people to learn about a setting is not good from a config management perspective.

Before #839, there were two groups of users: those who preferred this setting to be true, and those who preferred it to be false. For simplicity, let's say it was a 50/50 split. So, half have to learn about the setting, half don't. 50/50 happiness no matter which programming language.

Out of all VSCode users, the vast majority do not use Go. So there's numerous StackOverflow posts and other resources which help users who want this value to be false. This material makes it easy for the group of people who don't like the default value. A very small portion of these people ended up on this issue tracker, including the person in #839. Note how OP even answered that they didn't know about the setting and knowing about it solved their issue.

After the change, there are 6 groups of users:

1. Uses Go forever and want this to be false => Never learn about the setting
2. Started with Go and want this to be false => Have to learn about this setting as soon as they learn any other language
3. Move to Go from another language and want this to be false => Already know about this setting before moving to Go, and don't need to change anything.
4. Uses Go forever and want this to be true => Have to learn about the setting.
5. Started with Go and want this to be true => Have to learn about this setting. Doesn't need to change anything when changing to another language (it's default aligns).
6. Moves to Go from another language and want this to be true => Have to learn about this setting.

So out of these, 4 out of 6 groups who work with Go are not happy with this situation since they have to learn about the setting due to how it is set up currently. 1 out of 6 groups already know about the setting but don't need to do anything as they start using Go. Only 1 out of 6 groups are happy with the change. That is objectively worse than the 50/50 split.

Regarding #1815:

These issues are definitely related in the sense that I'd expect changes to global values to affect the language-specific value when it's unset in the language-specific configuration. This was a clear source of confusion for me with this issue too.

However, I also consider formatOnSave to be noticeably different from the setting discussed in this issue.

Most people encounter the formatOnSave setting while using an editor at one point or another, mainly because the state of auto-format tooling differs between languages. JS/TS for example had problems with formatting standards for a long time, some people used editorconfig, some used prettier, some used eslint, some with tsconfig, and so on. Same thing with many IDLs and config languages like YAML. For Go, there are established standards and great tools (gofmt, goimports), so most people probably want formatOnSave to be true.

So, going back to my argument about "not knowing about a setting is good". Most people will need to learn about formatOnSave sooner or later as they use different languages. Different defaults does not impact users as much.

This snippet setting however, is more exotic. I don't think that many people use snippets, and I can't think of a situation when you would want different behaviours for different languages.

Change https://go.dev/cl/412054 mentions this issue: docs/faq.md: entries on formatting issues

Change https://go.dev/cl/412383 mentions this issue: docs/faq.md: entries on formatting issues

The latest VS Code (1.79, 2023 May) changed the default of editor.suggest.snippetsPreventQuickSuggestions to false.

https://code.visualstudio.com/updates/v1_79#_quick-suggestions-and-snippets

In the next release, we will remove the language specific setting override since VS Code's default and what this extension wants as default now align.

Change https://go.dev/cl/502596 mentions this issue: package.json: align snippetsPreventQuickSuggestions with VS Code default

The latest VS Code (1.79, 2023 May) changed the default of editor.suggest.snippetsPreventQuickSuggestions to false.

https://code.visualstudio.com/updates/v1_79#_quick-suggestions-and-snippets

In the next release, we will remove the language specific setting override since VS Code's default and what this extension wants as default now align.

Good. What bothered me was the inconsistency between the global default and the extension's default, forcing all developers to become aware of the option. Now that the two will align, I'll close the issue.