Removal of vscode-cmake-tool custom debug buttons/functionality

[thernstig]

Brief Issue Summary

The CMake extension supports a custom debug or launch experience. But the experience creates a huge cognitive dissonance for how debugging/launching works for other programming languages and extensions in VS Code.

VS Code has a very specific way to configure launch/debugging via a launch.json. This is readily explained here https://code.visualstudio.com/docs/editor/debugging. As can be seen, it has its own Run and Debug icon in the activity bar.

VS Code by default also comes with the very common/default keyboard shortcuts F5 to start debugging, or Ctrl+F5 to run without debugging (launch).

Problems

There are multiple problems with the approach this extension has taken with a custom launch/debugging experience.

It is not visible in the Run and Debug view

Notice how the CMake extensions' custom debug options are not visible here. Only the ones from launch.json are:

The Status Bar shows double launch/debug buttons

A) is the default VS Code debugging/launch experience
B) Is the custom buttons add by the CMake extension

This "double the amount of buttons" is confusing.

The default debugging keyboard shortcut is overriden by the CMake extension

A) is the default VS Code keyboard shortcuts that launches the debug config selected in the Run and Debug view
b) Is the CMake extension that actually overrides the "without debugging" part for Ctrl+F5, which is a very bad user experience.

Hides implementation details

The custom CMake extension debugging hides all launch/debug details, and does not allow for users to easily set new options/overrides as can be done in launch.json, so everything is a bit of magic.

Solution

I strongly believe all this custom debug (status bar icons, keyboard shortcuts) etc should be removed. And that VS Code's builtin Run and Debug view/support should be used. This creates less information for users to learn since most are accustomed to other ways with other extensions and programming languages.

Instead all meny options such as CMake: Debug and CMake: Run Without Debugging should create default entries in launch.json when invoked if none exists. It simplifies a lot for users.

Additional references

https://github.com/microsoft/vscode-cmake-tools/blob/main/docs/debug-launch.md
https://code.visualstudio.com/updates/v1_94#_start-debugging-from-chat-experimental (might not work properly with the custom debug experience)

[mwerle]

Strong +1 from me; I regularly switch between CMake and non-CMake projects and it always takes me a bit of time to remember how this extension works if it's been some time.

I found this proposal after searching how to get the CMake extension to start a debugging session using just "F5"..

[thernstig]

@gcampbell-msft I want to add that even news like https://code.visualstudio.com/updates/v1_94#_start-debugging-from-chat-experimental most likely will not work well with the custom debug experience.

[gcampbell-msft]

@mwerle @thernstig To make things clear, we do not attempt to replace the typical debugging experience provided by VS Code, we only provide some attempts to make things easier when opening debug sessions. We still hook into the typical C++ debugging from the cpptools extension.

I definitely agree that the overriding of the default debugging shortcut makes this difficult, we plan to take #4125 after a CHANGELOG entry is made.

However, we will still take this feedback into consideration. Thanks

[thernstig]

@gcampbell-msft For all intents and purposes I think people do get thrown of by the custom/hidden debugging experience if not seeing it in the launch.json file. As explained in the original issue (last paragraph); adding the two run/debug configs to launch.json first time the commands are invoked would be "explicit over implicit". And more so mimic how every other debug extension does this for other languages afaik. But I am repeating myself now😆We have been heard 😃

(the "every other language" is a huge guess, but what I seen from the few I use)

[gcampbell-msft]

@thernstig I think that definitely makes sense, we appreciate your feedback and your patience.