Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upThe less settings the better #732
Comments
|
On top of this there is a lot of settins overlap how autoAttach can be enabled / disabled. For example one of the options for |
|
Also "debug.node.autoAttach": "disabled" puts it to |
Absolutely right! The |
|
The preponderance of auto attach settings specifically is something brought up in standup as well.
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? |
|
The only reason why The "on" and "off" states exist because the old "auto attach" feature is based on polling which has a cost. |
|
Great, so it seems like we are all aligned. |
This PR removes the hook in node-debug's auto attach, and uses only js-debug auto attach. As referenced in the linked issues, this involves removing `debug.javascript.usePreviewAutoAttach` and collapsing `debug.node.autoAttach` into `debug.javascript.autoAttachFilter`. The latter option gains a new state: `disabled`. Since there's no runtime cost to having auto attach around, there is now no distinct off versus disabled state. The status bar item and the `Debug: Toggle Auto Attach` command now open a quickpick, which looks like this:  The current setting value is selected in the quickpick. If there is a workspace setting for auto attach, the quickpick toggle the setting there by default. Otherwise (as in the image) it will target the user settings. The targeting is more explicit and defaults to the user instead of the workspace, which should help reduce confusion (#97087). Selecting the "scope change" item will reopen the quickpick in that location. Aside from the extra options for the `disabled` state in js-debug's contributions, there's no changes required to it or its interaction with debug-auto-launch. Side note: I really wanted a separator between the states and the scope change item, but this is not possible from an extension #74967. Fixes #105883 Fixes microsoft/vscode-js-debug#732 (the rest of it) Fixes #105963 Fixes #97087
This PR removes the hook in node-debug's auto attach, and uses only js-debug auto attach. As referenced in the linked issues, this involves removing `debug.javascript.usePreviewAutoAttach` and collapsing `debug.node.autoAttach` into `debug.javascript.autoAttachFilter`. The latter option gains a new state: `disabled`. Since there's no runtime cost to having auto attach around, there is now no distinct off versus disabled state. The status bar item and the `Debug: Toggle Auto Attach` command now open a quickpick, which looks like this:  The current setting value is selected in the quickpick. If there is a workspace setting for auto attach, the quickpick toggle the setting there by default. Otherwise (as in the image) it will target the user settings. The targeting is more explicit and defaults to the user instead of the workspace, which should help reduce confusion (#97087). Selecting the "scope change" item will reopen the quickpick in that location. Aside from the extra options for the `disabled` state in js-debug's contributions, there's no changes required to it or its interaction with debug-auto-launch. Side note: I really wanted a separator between the states and the scope change item, but this is not possible from an extension #74967. Fixes #105883 Fixes microsoft/vscode-js-debug#732 (the rest of it) Fixes #105963 Fixes #97087
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:
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.