The less settings the better

[isidorn]

Refs: microsoft/vscode#105771

I noticed that we introduced quite some settings for debug.javascript while most of this make perfect sense I just wanted to share my thoughts that:

• The less settings the better
• No need to intrdouce a setting only if a couple of users ask for it. Nobody will always be happy.
• Less settings, less complexity
• We depracte the "use preview" settings once things go out of preview

I did not really review all of them but there are some quite obscure ones, like for example
"debug.javascript.warnOnLongPrediction"

Just my 2 cents.

[isidorn]

On top of this there is a lot of settins overlap how autoAttach can be enabled / disabled.
"debug.node.autoAttach": "off",
"debug.javascript.usePreviewAutoAttach": false,
"debug.javascript.autoAttachFilter": "explicit",

For example one of the options for autoAttachFilter could be never

[isidorn]

Also "debug.node.autoAttach": "disabled" puts it to off and hides it. This is not proper, since this setting should not control the UI. Users can expiclitly hide any item in the status bar.

[joaomoreno]

Also "debug.node.autoAttach": "disabled" puts it to off and hides it. This is not proper, since this setting should not control the UI. Users can expiclitly hide any item in the status bar.

Absolutely right! The disabled vs off difference isn't obvious. Once I grokked it, it's just a matter of controlling the visibility of a status bar action, for which we already have core functionality.

[connor4312]

The preponderance of auto attach settings specifically is something brought up in standup as well. debug.node.autoAttach is the 'old' setting and debug.javascript.usePreviewAutoAttach is toggling with the old behavior. Next month, provided things go well, I want to remove both these settings and add a never setting to debug.javascript.autoAttachFilter which would be the same as 'disabled'.

debug.javascript.warnOnLongPrediction -- good suggestion, I added this way back when I started working on VS Code, this should be an item in the workspace state, not a setting.

Absolutely right! The disabled vs off difference isn't obvious. Once I grokked it, it's just a matter of controlling the visibility of a status bar action

This was existing functionality, cc @weinand. I wonder if we need a button at all once js-debug auto attach is implemented, since at that point auto attach will be fairly passive. Thoughts?

[weinand]

The only reason why debug.node.autoAttach has a "disabled" state is that it was introduced before we were able to control the visibility of status bar actions via core functionality. Since not every user is a node.js user, and we are shipping with a builtin node debugger, we needed a way to hide this node.js specific status bar item for Python, Java, etc. users.

The "on" and "off" states exist because the old "auto attach" feature is based on polling which has a cost.
Since the new "auto attach" no longer uses polling, we can remove the "on" and "off" settings since we have the "autoAttachFilter" for controlling how "aggressive" ;-) auto attach is.

[isidorn]

Great, so it seems like we are all aligned.
Apart from the above I suggest we review the other debug settings and figure out if they are really needed / or if their description could be improved.