List install VS Code extensions as part of --doctor

[andyw8]

Just a little idea I had: What if we list the extensions as part of --doctor to aid with troubleshooting? The intention would be that people can paste this into an issue.

[st0012]

I feel ruby-lsp's flags should aim for server functionalities. Therefore, --doctor should focus on diagnosing server issues and listing VS Code-specific output with it doesn't feel quite right.

Also, some users may have code installed but use other editors (like I used to). And in this case, could having this output be misleading?

But I think it's ok to give it a try first as it's easy to drop if not helpful.

[st0012]

Let's add some of output to make this section's purpose clearer. Something like:

  puts
  puts "======== VS Code extensions ========"
  puts

indexing: /Users/hung-wulo/.gem/ruby/3.3.4/gems/sorbet-runtime-0.5.11481/lib/types/types/union.rb
indexing: /Users/hung-wulo/.gem/ruby/3.3.4/gems/sorbet-runtime-0.5.11481/lib/types/types/untyped.rb
indexing: /Users/hung-wulo/.gem/ruby/3.3.4/gems/sorbet-runtime-0.5.11481/lib/types/utils.rb

======== VS Code extensions ========

aaron-bond.better-comments@3.0.2
alefragnani.project-manager@12.8.0
bierner.markdown-mermaid@1.23.1
....

[vinistock]

In addition to that, I think we need some explanation of why this is being shown. It may not be obvious to the user why we're printing their VS Code extensions.

Something along the lines of Having other Ruby related VS Code extensions may conflict with the Ruby LSP's behaviour. Here are the currently installed extensions. Could the problem be coming from a different extension?.

Also, this will list private extensions too, so we may need some sort of warning indicating that. We wouldn't want people to accidentally paste information about private extensions into issues.

[st0012]

Another idea: should we instead add a Ruby LSP: Diagnose Issues VS Code command? In that case, we can call ruby-lsp --doctor and then print the extensions, without adding the VS Code specific thing to the --doctor flag.

Additionally, we can also list users' rubyLsp settings and perhaps launch.json entries, which will be super helpful too. If the server is started, we can list addons as well.

(By print, I mean maybe writing the output to a blank file (with name like ruby-lsp-report.txt?) in the VS Code)

[andyw8]

Good ideas

[Earlopain]

Stock VSCode is surely by far the most popular flavor but there are other like VSCodium https://github.com/VSCodium/vscodium which enjoys some usage. Another plus when delegating this to the extenion since it uses a different binary name and code doesn't exist, or worse, prints entirely different extensions.

Edit: Code Insiders would probably also fall under this category.

[andyw8]

Doing it in the extension may also allow us to know which extensions are enabled rather than just installed.

[st0012]

@andyw8 do you still want to add extensions to --doctor flag after #2456?