feat(0.8): Move language-specific plugins into language extensions

[sjcobb2022]

I have verified that this feature request has not been made before

• [x] I have checked the issues tab, and did not find a similar feature request. I understand that my issue will be closed if it is a duplicate.

Feature Type

Other

Feature description

Proposal

• Default to configuring language servers with vim.lsp.config.
• Provide an opt-in vim.languages.<lang>.extensions to let language-specific plugins (e.g. rustaceanvim, haskell-tools.nvim) take over LSP management by disabling the built-in enable for that server. Similar to how we have done it with crates.nvim

Example

{
  vim.languages.haskell.enable = true;
  vim.languages.haskell.extensions.haskell-tools-nvim.enable = true;

  vim.languages.rust.enable = true;
  vim.languages.rust.extensions = {
    rustaceanvim.enable = true;
    crates-nvim.enable = true;
  };
}

Notes

• When an extension is enabled, ensure the corresponding vim.lsp.enable is disabled to avoid double-registration. (breaks things)

Compatibility references

• https://github.com/mrcjkb/haskell-tools.nvim/commit/53d9888aebe27cd50c0404d88a7aa51d7341784a
• https://github.com/mrcjkb/rustaceanvim/pull/660

Alternatives

No response

Additional Context

No response

[NotAShelf]

I think this could be a valuable addition. The requirement of plugins to set up basic language modules has been nagging me for a bit, and moving to base vim.lsp and enabling rustaceanvim & friends (both of which are very invasive imo) could be the way to go. Though I'd like to discuss this a bit further.

Namely, I want to debate what we'd lose by making those disabled by default (since extensions are disabled by default) and the discoverability of those options. It is often times the case where users don't notice an option, and remain blisfully unaware of nvf's capabilities.

[horriblename]

rustaceanvim and haskell-tools.nvim are fairly advanced tools, and offers much more that LSP/DAP. haskell-tools explicitly states that new-comers should use lspconfig for hls config, and only advanced users need haskell-tools. Anyone looking for advanced features (hopefully) knows the plugin's existence and will check for themselves. Everyone else using LSP only isn't even going to realize haskell-tools absence.

I'm not sure if this applies for all language plugins though

[sjcobb2022]

I second this, I use rust-analyzer without rustaceanvim a lot as well, and it is perfectly fine without it. It does add a couple of niceties such as in-place running of tests, but is not necessary for basic use.

Perhaps we could advertise the features more prominently somehow to help with visibility. Put it in the maximal configuration perhaps, or mention it in an obvious place in the docs (like at the top of the language-support) section?

[sjcobb2022]

Could also add a deprecation warning as well in the changes to languages.rust saying that it no longer uses rustaceanvim by default.

[NotAShelf]

I think as of 0.8 we use plugins for the rust, haskell, scala and flutter language modules. Amongst those four I recall flutter being really annoying to deal with without a plugin (so much so that we discarded the idea outright at the time of addition) but we can at least give it a try.

Perhaps we could advertise the features more prominently somehow to help with visibility. Put it in the maximal configuration perhaps, or mention it in an obvious place in the docs (like at the top of the language-support) section?

The correct place to put such a message would be the breaking changes section in the changelog, but I am beginning to think we want a section in the documentation for specific components, such as the language components.

Could also add a deprecation warning as well in the changes to languages.rust saying that it no longer uses rustaceanvim by default.

I don't think there is a good condition to bind this warning to; it is enabled unconditionally while the rust langauge module is enabled, which we cannot use as a condition in the warning bit. The best we can do right now is documenting it very well and hoping the people read.

[sjcobb2022]

The correct place to put such a message would be the breaking changes section in the changelog, but I am beginning to think we want a section in the documentation for specific components, such as the language components.

Yeh I think this is the right approach.

Would you like me to start on this?