Intellisense support is disabled when using the .code-workspace file

[bettinaheim]

In order for intellisense to be fully activated, the workspace folder needs to be the top level katas folder. Maybe this can be configured in the file?

[tcNickolas]

Could you please provide more details on which parts of IntelliSense are not activated with the current setup? I don't use VS Code a lot, but I noticed that in Visual Studio the katas which have a dependency on utilities/Common (for CounterSimulator) can't recognize the namespace or the operations from that project. Is this the same issue or a different one?

[tcNickolas]

I see that some of the information IntelliSense shows on mouse hover differs in VS Code depending on where the file was opened from - if opened from root it shows full help for, say, X gate, but if opened from one of the kata folders it shows just "Variable X". Is this the behavior you're referring to?

Unfortunately, I'm not familiar with the management of workspace folders in VS Code. A quick search through the settings docs doesn't show anything similar to setting workspace folder. @cgranade You know VS Code a lot better than I do - any suggestions?

[cgranade]

I suspect this has to do with multifolder workspace support in the VS Code extension. Ideally, each folder in a workspace would get its own instance of the language server.

One thing that might be helpful is to look at the output log for the extension, as that might mention if there's a project it can't load or something of that form that's easier to knock out. Press Ctrl+Shift+U and then select the Q# extension from the dropdown list on the output panel.

[bettinaheim]

When filing this I was basically hoping there might be a handle in the .code-workspace file to define a working directory that we could leverage. From what I gather there unfortunatly isn't. I would hence suggest to actually remove this file from the repo, since the benefit of having it seems a bit limited.

[cgranade]

For Visual Studio Code, a .code-workspace file lets you suggest a multifolder workspace and provide settings for the new workspace, much in the same way that the .vscode folder lets you provide settings for a single-folder workspace. We've used that in the case of the katas to provide a separate set of test/build tasks for each individual kata, and to provide settings that simplify the presentation of the katas (e.g.: by suppressing false positive error messages from the C# extension).

The other advantage we get from providing a .code-workspace file is that it gives GUI-oriented participants something to double-click on. The quintessential workflow for VS Code is centered around opening folders. While this is very similar to Sublime Text, Atom, and many other modern text editors and IDEs, we've run into that some users find it to be counter-intuitive to first open a folder in VS Code and then use the built-in explorer to navigate files within that folder. Since the language server is only really functional in open-folder mode (similar to most other language support in VS Code), giving users a double-click target avoids confusion over missing language support.

All that said, I definitely agree that until we get multifolder workspace support in the VS Code extension, we run into limitations with the .code-workspace approach as well. One path forward might then be to start extracting the language server lifecycle from the extension lifecycle so that we can launch new instances of the language server as folders are added to a workspace. I'll go on and create feature requests over at qsharp-compiler to track the planning for that feature.

[tcNickolas]

Looks like the consensus is that there is no action possible in the QuantumKatas repo to mitigate this issue. Closing this issue as "won't fix".