Add some diagnostic logging for ruby-lsp

[marknuzz]

I have checked that this feature is not already implemented

• [X] This feature does not exist

Use case

I think it would be great to have some more support to view diagnostic logs on the ruby-lsp. It seems more important to have that when there are features like formatter autodetection, where you might want to know what formatter is being used, what the command args are, etc.

Description

Show more info in the output window

Implementation

Things like "which formatter was selected, which configuration was used, etc" get shown in the ruby-lsp output window. Maybe this can also be a toggleable feature if there is a concern it is too noisy

[Nakilon]

I wish I could debug why my configuration doesn't apply.

On Sublime Text 4 I tried to disable Rubocop:

{
  "clients": {
    "ruby-lsp": {
      "enabled": true,
      "command": [
        "ruby-lsp"
      ],
      "selector": "source.ruby",
      "initializationOptions": {
        "enabledFeatures": {
          "diagnostics": false,

          "codeActions": false
        },
        "formatter": "none"
      }
    }
  },
  "inhibit_snippet_completions": true
}

I see in LSP logs that it was passed:

  'initializationOptions': {
    'enabledFeatures': {
      'codeActions': False,
      'diagnostics': False
    },
    'formatter': 'none'
  }

but it's still everywhere:

[vinistock]

Thank you for the report. Concerning the problem related to disable features, that was fixed in https://github.com/Shopify/ruby-lsp/pull/2071 and released with version v0.17.

In this specific example, logging the things you mentioned wouldn't have helped diagnose the problem because the issue was not related to auto detection of the formatter/linter, but rather a mistake in processing initialization options.

The team is definitely not opposed to add more logging using logTrace, but can you be specific about the exact things that would be helpful logging?

Which formatter got selected is concrete and we can definitely add that. But which configuration was used is a bit generic. Is that logging the initialization options? Or the internal state of our global state object? If it's the internal state, what parts of it should be logged?

[marknuzz]

In my case I would be happy enough to see the formatter that was selected, and the initialization options used, in the output window for "Ruby LSP", and this would either show up by default, or instructions on how to enable the logging would be in the Github vscode/README.md (not buried somewhere deep in the docs site)

On that note, seems anything related to logging is here, under "CONTRIBUTING"? That's frankly the last place I would have checked. I did find this though, which just printed a bunch of garbage 'typed strict'. Maybe there's a misunderstanding in the sense that the actual use cases for having logging is not limited to contributing or extending the LSP, but rather also covers a wide range of troubleshooting situations that any user may have.

[connorshea]

I'd definitely like to see the rubocop version that is being used in the logs, that's the main thing I'd want to see in the logs. Maybe even the entire custom gemfile that's being used?