Improve displaying symbols documentation

[tomwyr]

Currently the documentation opens every new symbol in a separate web view window which quickly makes the workspace messy, if users navigate to nested symbols (open symbol docs from already opened documentation window). The PR addresses this issue in the following way:

• Opens symbol documentation window in new column or nearest non-editor column (user opens the documentation for the first time or has the documentation already open, switches to the editor and opens another symbol)
• Opens symbol documentation window in current column if it is a non-editor column (user has the documentation already open and focused, then opens another symbol or clicks on a symbol link)
• Adds simple configuration that lets user switch to additional active placement option
• active placement always opens new documentation windows in the active tabs group

[DaelonSuzuka]

Very cool, improving this behavior definitely makes the in-editor docs more useful.

I'll check this out tonight and let you know if I have any suggestions.

[tomwyr]

Thanks, looking forward for your feedback.

[DaelonSuzuka]

This feature works great and the code looks good to me.

My only question is why you updated @types/vscode in package-lock.json (lines 88, 1891), but not on line 27, or on line 393 of package.json. Or how engines/vscode (package-lock.json#34, package.json#18) can be 1.33.0 if we're referencing the types from version 1.69.1.

I have to admit that I don't fully understand node dependency management. Maybe @Calinou has some input here?

[Calinou]

I have to admit that I don't fully understand node dependency management. Maybe @Calinou has some input here?

To be fair, I don't really understand how types packages are managed either.

[DaelonSuzuka]

If I install @types/vscode at version 1.67.0 or 1.68.0, it has the vscode.window.tabGroups definition that this PR requires, and also doesn't vomit garbage when I run npm run compile.

[tomwyr]

That's a very good catch. The code uses vscode apis added in one of the releases >1.33.0 so package.json should be also updated. I'll take a look into vscode changelogs to see which is the min version we need to use tabGroups.

[tomwyr]

Unless you think it's fine to bump vscode types version to the newest one. @DaelonSuzuka

[DaelonSuzuka]

I'll take a look into vscode changelogs to see which is the min version we need to use tabGroups.

I was too lazy for that: I just did a binary search by running npm install @types/vscode@foo until I found a version that had tabGroups.

1.66.0 and earlier do not have tabGroups.
1.67.0 and 1.68.0 have tabGroups but do not break the build.
1.69.1 and 1.70.0 (which is the latest) both break the build, but I'm not sure why yet.

I recommend just running npm install @types/[email protected] in your local repo. That should correctly update package.json and package-lock.json.

I also think you should leave the other package versions and the engine version alone, and we'll deal with that in a separate operation.

[tomwyr]

Thanks for checking that out. I updated @types/vscode via npm install so the version has changed in package.json (although build will fail as you said since the engine version doesn't match the types).

[DaelonSuzuka]

(although build will fail as you said since the engine version doesn't match the types).

You are absolutely correct, that's my mistake. I thought the engine version was already out of date with the types, so you leaving it out of date would be fine.

Since it looks like that's the only thing failing the build, if you update the engine to 1.68.0 in both files, this should be ready.

Sorry again for the confusion.

[tomwyr]

Got it, that's actually what I thought too. The engine version now matches vscode types so the packaging script will (hopefully) pass.

[DaelonSuzuka]

@tomwyr Thanks for your contribution!