Improving Editor Setup and First Use for neophyte

[antoniocaruso]

After an interesting email exchange with @bobbrow, I opened this discussion.
The idea is to focus on 'fist contact with VSC' and in particular for students, or other people that are learning to program. Since VSC is not a competitor to VS, it is important to care about people that use 'in the community', that are not expert developers.

I raised two problems that has been already discussed in several Issues without a clear solutions.

• setup vsc from the very beginning without managing configurations options, or .json files. In particular: the setup of a proper path for compilers / libraries / includes must be as straightforward as possibile.
• offer the possibility to 'just compile', no project involved, no makefile, just a simple compile. Offer the possibility to setup compiler options and language standards (c99,C2x,C++-xx) easily. no debugging involved.
• offer the possibility to 'just run', and setup the command line arguments.
• if all the above work in a very simple manner, then add other stuff, like support for complex tools, debugging, and so on. Taking into account the learning path of people.

Compilers: The scenario that I consider is always the same. The user can download easily a zip file with all the proper compilers and build environment, for example the ones provided by mingw64. So, I assume that there is a directory that is already unzipped somewhere in the file systems, for example in C:\mingw64.
There is however no change in the system PATH. So this must be taken into account.

Problems:

1. C++ Walkthrough do not work. There is a button with "Select Default Compiler" that 'don't work'. I mean, it open the command palette, with options to select a compiler, like:
   • select g++ in C:\mingw64\bin
   • select gcc in C:\mingw64\bin
   • select other compilers
     if you select the first option, it still open a file request window, (why?) and if you select the compiler (it is not clear if the selection must specify a path to a folder or to a binary). NOTHING HAPPEN.
     No feedback, no real communication to the user. I expected something like 'ok, Default Compiler = c:\mingw64\g++', just to know that it worked. But there is no feedback.

Moreover, if you try to compile, the tool is used without a path, and the PATH in the subshell is not set, so the final outcome is
g++: command not found.

I hope the community would consider that all this scenario is not appropriate to a 'community edition'. If people want to work with a real IDE, they download 20GB of data and install VS. Then there is no need to use VSC.

[bobbrow]

Hi @antoniocaruso, I'll try my best to go through these issues and explain where we are currently at as an extension and probe where you think we might be able to do better. Configuration is one of the areas where we receive a lot of feedback, and we've tried a lot of ideas out to make things easier for people, so we're always open to learn of new opportunities to make this better.

However, I ask that you please be patient with my response times as my day is booked with meetings and I have a lot to say about the problem areas you've mentioned. I may end up doing one at a time as individual responses depending on how my availability looks this week.

Thanks for understanding!

[antoniocaruso]

no worries, I can understand.

[bobbrow]

Issue 1

• setup vsc from the very beginning without managing configurations options, or .json files. In particular: the setup of a proper path for compilers / libraries / includes must be as straightforward as possibile.

Today's behavior

The C++ extension automatically searches for compilers it knows about. If the compilers it finds are in a location we can trust (e.g. Program Files folder on Windows, or in the PATH environment variable on all systems), the extension can automatically activate IntelliSense for one of those compilers. In a lot of cases, this "just works" for people IF they have a compiler installed already and no manual configuration is required.

You mentioned mingw which is installed directly under the C: drive by default. We originally trusted this path by default and it used to "just work", but as a result of a security bug opened against us by the community, we had to revoke trust for this path and now ask for confirmation from the user before activating IntelliSense with this compiler. Once they have confirmed, we shouldn't bother them again about it. The compiler will be saved in the c_cpp_properties.json configuration file automatically.

To deal with libraries and includes, we default to a special configuration mode we refer to as "recursive includes." This means we will attempt to resolve #include directives by matching them to any header file with the same name/relative path that we can find in the open workspace. In a lot of cases this also "just works" for people IF the includes/libraries reside in the workspace folder. Compiler includes (such as the standard library) generally do not reside in the workspace folder which is why we do the compiler discovery stuff mentioned earlier. If you're using the vcpkg package manager for libraries, we are also able to detect the out-of-workspace path to the library includes and automatically add those to the include path.

Additional strategies we employ include:

• extracting configurations from a compile_commands.json file which might be generated by your build system.
• requesting configurations from VS Code build system extensions such as "CMake Tools" and "Makefile Tools." If you have one of these extensions configured, we should automatically configure C++ for you without any manual interactions.

If all of these automatic strategies fail and it looks like the workspace is still unconfigured, we will then show a warning on the status bar that will prompt the user to take additional action when clicked. The "Select IntelliSense Configuration..." command that will be launched provides some of our best guesses as to what you might need to do to get IntelliSense at least partially configured and it also provides a command that can help you install a compiler if you don't have one already.

What's next?

We are aware of several embedded compilers that do not work the same as the main 3 (GCC/Clang/MSVC). Some of them are quite popular, but we don't have a way to get information out of them to auto-configure IntelliSense. We have been working on a way to support more compilers, but it is not ready yet and had to be postponed a few releases. #6931

We could certainly use your feedback on any scenarios we've missed. There are various build systems for C++, so we have been unable to reach everyone's use cases. But we have covered several common scenarios already and could potentially cover more if you'd like to outline what didn't work for you that you'd like to see work automatically in the future.

[antoniocaruso]

Ok,

If C:\mingw64 cannot be trusted by security reasons, it is difficult to solve this problem.
I can solve all issue by changing the windows global environment variable PATH, and put
that dir in the PATH. Maybe it is the easier way.

In any case, I suggest to the authors of the 'Getting Started with C++' to change it. Because, if
this is for 'getting started' it DO NOT WORK. It assumes that you have Visual Studio installed, or
a compiler in the PATH, it does not work in another way.

And it do not provide ANY feedback. Anything. Please test it. You will see, but TEST it on a machine
without Visual Studio installed.

If you push on 'Select my Default Compiler', the 'effects' of this totally confusing, please TEST IT.
It opens the command palette, and ask you to set the path for the compiler, (I have it already set
to mingw/g++) but if you come back to this procedure there is no feedback that it is already set.
Under this button I expect to find: 'Current Compiler Path: C:\mingw64' or whatever.

[bobbrow]

I just looked through the scanning code and c:\mingw64 is not in our list of paths to search since we weren't aware of an installer that put the compiler in that location. If I'm understanding correctly, you are downloading a zip file with the tools and unzipping them to c:\mingw64. I did that and can confirm that the extension failed to find a compiler. Renaming the folder to c:\mingw causes the extension to find it.

This setup you're using is different from what our 'Getting Started with C++' document describes, but we could add a note for other installation types to update the PATH.

And the fix for this issue is easy - we can add c:\mingw64 to the list of paths we search. Then you will get compilers in the drop down list and can easily pick g++.

If you push on 'Select my Default Compiler', the 'effects' of this totally confusing, please TEST IT.
It opens the command palette, and ask you to set the path for the compiler, (I have it already set
to mingw/g++) but if you come back to this procedure there is no feedback that it is already set.
Under this button I expect to find: 'Current Compiler Path: C:\mingw64' or whatever.

This is good feedback. I will open an issue to make this better.

[bobbrow]

Issue 2

• offer the possibility to 'just compile', no project involved, no makefile, just a simple compile. Offer the possibility to setup compiler options and language standards (c99,C2x,C++-xx) easily. no debugging involved.

Where we are today

There are many ways to declare and orchestrate C++ project builds. Due to the lack of a uniform way to build C and C++ programs, the C++ extension has abstained from trying to build in support for any one build system. Instead, we have delegated build system support to other extensions such as the CMake Tools and Makefile Tools extensions.

For simple compilations of a single source file, we added a "play" button in the editor. Clicking this button prompts you to select which compiler you'd like to build with and then produces an exectuable that will be run with or without a debugger attached.

This process generates the tasks.json file for you to remove the hassle of setting up the basics. This file can be edited if you want to change any of the default settings (including language standard, library dependencies, output location, etc.)

What's next?

There's not a lot planned in this space right now. We've considered attempting to link the IntelliSense configuration to the build tasks but do not yet have a design that we think will work effectively and not confuse users.

We've also considered adding a side panel that would allow people to organize their source files into libraries and executables that we could build for them. But we are not committed to this right now as we are hesitant to invent yet another build system, especially since it would be one that only works within VS Code. We could consider designing a side panel to organize build tasks and allow some customization to it, but we're not sure what this would look like yet.

If we were to offer the possibility to set up compiler options for our "play" button, what would you be looking for, and how would you expect it to be presented to the users such that they can discover the feature and use it? Would you expect it to be able to compile more than one file at a time, or just the current file? Would you like an additional option on the "play" button to "just compile" without running or debugging the executable?

[antoniocaruso]

I solved it with 'Code Runner' extension.

[bobbrow]

Issue 3

• offer the possibility to 'just run', and setup the command line arguments.

Where we are today

We have the capability to "just run" the executable that we build with our "play" button described in my response for Issue 2.

For configuring the command line arguments, there is a gear button next to the "play" button in the editor that will generate a launch.json file where command line arguments can be added to the "args" array.

What's next?

We've considered building a feature to allow users to identify the executable that they'd like to run in VS Code and help them set up tasks.json or launch.json for those executables. Users then build those binaries using whatever method they prefer and we can help with the "run" and "debug" steps.

We do get feedback about folks not wanting to edit json files though. We created a web page view of our IntelliSense settings and could potentially do something like that for build and run/debug settings. However, we have avoided creating workarounds for configuration files that the VS Code team owns as we think it would be more appropriate for VS Code to support this so that all users can benefit from it, not just C++ users. It doesn't mean we couldn't do something here ourselves, but we would consult with the VS Code team first.

[antoniocaruso]

like (2)

[bobbrow]

Issue 4

• if all the above work in a very simple manner, then add other stuff, like support for complex tools, debugging, and so on. Taking into account the learning path of people.

What's next?

Could you provide a few more specifics around what you are asking for here? What "complex tools" are you referring to?

I mentioned a feature to help guide users through the run executable/debugger configuration process in my response for Issue 3. We could use that thread to discuss expectations/needs for that task.

[antoniocaruso]

Bob just imagine a class with 100 students and the 'learning path' for a C, or C++ course. for a FIRST programming course.
For me, 'complex tools' are: github, gdb, and make, int that order. They will use them, not before half of the course, and they
always like an environments that 'just work'. Remember, they are a generation that do not know how to use a command line.
Definitelly a guide to 'debugging' would be a good thing.