Avoid unnecessary warnings in the checkhealth report; perhaps filter which tests to run accordingly.

[EdmundsEcho]

I've searched open issues for similar requests

• [X] Yes

Is your feature request related to a problem? Please describe.

First, this is a great plugin. I love it! I hope this feedback contributes to the quality of the work.

The problem is that mason generates unnecessary warnings in the checkhealth report.

Describe the solution you'd like

Where we have in the lua/mason/health.lua module

    a.wait_all({ 
        check_thunk({ cmd = "go", ... }),
        check_thunk({ cmd = "cargo", ... }),
        check_thunk({ cmd = "luarocks", ... }),
        check_thunk({ cmd = "ruby", args = { "--version" }, name = "Ruby", relaxed = true }),
        check_thunk({ cmd = "gem", args = { "--version" }, name = "RubyGem", relaxed = true }),
        check_thunk({ cmd = "composer", args = { "--version" }, name = "Composer", relaxed = true }),
        check_thunk { cmd = "php", args = { "--version" }, name = "PHP", relaxed = true },
        etc...

These checks generate of bunch of warnings that "stick out" in my checkhealth report, warnings that made me wonder if I had inadvertently activated all of the lsps.

Option 1 (solves the problem)

Have the check be dependent on the user having configured mason to manage the lsp.

Option 2 - update the warning message

At minimum update the warnings to let the person know there isn't anything to do.

Option 3 - only fire Errors

Just get rid of the warnings and only report when a test fails when the user has activated the lsp.

Describe potential alternatives you've considered

I would be happy to contribute with just a little bit of guidance. In particular, I would want to know where in the mason runtime state, it maintains the user configurations... i.e., the list of activated lsps. I know that the companion plugin maintains a list of lsps, but that's presumably not something mason has access to.

Finally, perhaps the lsp-specific health tests should be run using the companion plugin, and not mason. This makes sense given it's the use of the mason-lspconfig plugin where the user has clearly "signalled" that it wants mason to specifically manage more about the lsps.

Next steps

Fix mason?

Where in the runtime code can I access information about the lsps?

Augment mason-lspconfig

Where in the runtime code can I access information about the list managed lsps?

Additional context

A check health report is a place I go to diagnose issues that I should address. The report is likely done when I'm trying to problem-solve something. Warnings can be indicative of a problem. That is not the case here and, thus, an issue that may be worthwhile to consider.