Allow Code Lens features to be configured at a more granular level

[andyw8]

https://ruby-dx.slack.com/archives/C0515KVRNE4/p1690113893796309

e.g. allow the Gemfile Code Lens to be disabled independently from the test running ones.

We would still want to have a single Code Lens request, but adjusted to accept a configuration option.

A corresponding change will be needed for vscode-ruby-lsp.

We may also need to to consider how to 'migrate' users to the new configuration.

[snutij]

Hello @andyw8 👋 I can take a look at it. Any guidelines for the implementation?

[github-actions]

This issue is being marked as stale because there was no activity in the last 2 months

[simonc]

Hi there! 🙂

I would have been really interested in this feature. Being able to disable the Gemfile Code Lens would be 👌

Cheers ❤️

[vinistock]

@snutij sorry about the delay. To support this we will need to start receiving inlay hint configurations from the initialize options, similar to what we do for formatter.

We'd need to store the configuration for inlay hints in the Store class and then pass it to inlay hint here.

I think we can define the options structure to be like this

{
  inlayHint: {
    gemLinks: false,
    implicitRescue: true,
    implicitHashValue: false,
  }
}

I'd start with only the rescue hint enabled by default since it seems this feature is quite controversial. Then in the inlay hint request implementation, we'll need to use the configuration to decide which hints to push to the response.

After the server supports the new config, then we need to change the extension to surface this in VS Code.

We will need a new setting using an object type, where each property is the name of the hint with a boolean value (to match the server). Then we need to read the configured hints and send them to the server as part of the initialization options.

[snutij]

Hello @vinistock, thank you very much for the guidance 🙏

This issue was about the Codelens request, which is used to generate links to gem repositories in Gemfile. It's not the same that InlayHint, even if the need, and implementation will most likely be the same. Should the two be treated at the same time? And if not, which is the higher priority for you?

Btw, I will handle it, feel free to assign it to me 🚀

[vinistock]

Oh, yeah. I'm sorry I confused the issues. Let's go with a configuration object for all requests then, so that we can use it in code lens and in inlay hint. Then we can pass the configuration object relevant to each request.

Something like

// Initialization options
{
  featureConfiguration: {
    codeLens: {
      gemfileLinks: true,
    },
    inlayHint: {
      implicitRescue: true,
      implicitHashValue: false,
    }
  }
}

In terms of priority, I would start with inlay hint since people have been asking for that more often than code lens.

I'll assign the issue to you. Thank you so much for looking into it 🙏.