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

[sjcobb2022]

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

• 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

• mrcjkb/haskell-tools.nvim@53d9888
• feat(lsp): preliminary support for vim.lsp.config mrcjkb/rustaceanvim#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?

[NotAShelf]

I think it'll be a good idea to migrate the remaining extensions to the extensions namespace, but I'm a little unsure how we handle frameworks vs tooling vs goodies. Astro is a framework, but as far as I'm concerned you will never write it without the JS/TS module. The recent Vue PRs have shown me that this:

1. Creates an ambiguity,
2. Confuses potential contributors.

Let us discuss this a little further before proceeding. I think #1304 also shows us that there should be a kind of abstraction between language modules and the vim.lsp API that's neither low-level or high-level. Something that allows us to provide pre-defined LSP configs on top of vim.lsp perhaps...?

[sjcobb2022]

Are you proposing perhaps an intermediary level that maps between our API? Personally I think the typescript ecosystem is a bit of an outlier here. The effort to implement another intermediary may be a bit overkill.

Astro is a framework, but as far as I'm concerned you will never write it without the JS/TS module.

I still think it is valuable to be able to decouple these modules though, purely for the reason that astro is inherently module, and so one may write astro with svelte or astro with jsx, and those are both realistic use-cases. This is of course, not the same case for vue.

I believe at some point in the migration to vim.lsp.servers API, that it could be valuable to completely separate out the lsp definitions into their own files like is done in nvim-lspconfig. E.g. we have a folder in the plugins/languages, that has a list of the available lsp servers.

Taking this a little further, we could map to "bundles" of configuration instead of a single vim.lsp.servers instance.

It may be reasonable to also provide some reasonable defaults, like enabling TS by default when you enable Vue etc.

[horriblename]

there should be a kind of abstraction between language modules and the vim.lsp API that's neither low-level or high-level. Something that allows us to provide pre-defined LSP configs on top of vim.lsp perhaps...?

It sounds like you're thinking of having 3 layers of abstraction, which imo is a bit much for this, I think we can add the base configs for various LSPs right inside vim.lsp.servers, e.g.

options.vim.lsp.servers = mkOption {
  type = submodule {
    freeformType = attrsOf (submodule {
        # unfortunately the `enable` name is taken by the "auto-start" feature so here's a verbose name
        # this options adds the config to the init script
        includeInConfig = mkEnableOption "..." ;
        # old options
        enable =... ;
        settings =... ;
        capabilities =.... ;
        #... 
    }) ;
    options = {
      ts_ls = {
        cmd = mkOption { default =...; ...} ;
        ... 
      };
      # all other LSP, for all languages
      java_lang_server =... ;
      clangd =... ;
      #.... 
    };
  } ;
};

# usage
config.vim.lsp.servers = mkIf javaCfg.lsp.enable {
 vim.lsp.servers.java_lang_server.includeInConfig = true;
};

this way the defaults all show up in the docs (which might be a bad thing considering how verbose some of them are), and we get rid of all the code duplication in ts/svelte/astro etc.

[horriblename]

regarding whether or not svelte/astro etc should be collapsed into ts, I think the current structure is better since you can more easily pick a different formatter/lint for svelte and ts and astro, though maybe it's not something anyone cares about?

[NotAShelf]

Are you proposing perhaps an intermediary level that maps between our API? Personally I think the typescript ecosystem is a bit of an outlier here. The effort to implement another intermediary may be a bit overkill.

It sounds like you're thinking of having 3 layers of abstraction, which imo is a bit much for this, I think we can add the base configs for various LSPs right inside vim.lsp.servers, e.g.

You are probably right. I was a little concerned that the language modules could not be used for this purpose because they do a bit much (LSP, Treesitter, plugins, etc.), but in reality this is quite literally what they were designed for and all of those have toggles.. We can defer to vim.languages for a variety of language things. Forget about the intermediary abstraction.

I'm not sure how much of an outlier TS is, but if a system cannot handle such a trivial outliner then the system is flawed imho. The correct approach would be handling everything consistently and intuitively. For Vue specifically, I think it makes sense to make it a language module in the name of visibility and not complicating the TS module.

regarding whether or not svelte/astro etc should be collapsed into ts, I think the current structure is better since you can more easily pick a different formatter/lint for svelte and ts and astro, though maybe it's not something anyone cares about?

They are equally visible in the documentation (thus more discoverable in termrs of options), and I think we should be more concerned with visibility, clarity and maintainability over semantics. Technically speaking, Vue is generally regarded as a language rather than a framework so a languages.vue is not semantically incorrect either. Cramping everything under one module is confusing, and from our perspective, unmanagable.

I believe at some point in the migration to vim.lsp.servers API, that it could be valuable to completely separate out the lsp definitions into their own files like is done in nvim-lspconfig. E.g. we have a folder in the plugins/languages, that has a list of the available lsp servers.

This is pretty much what I had in mind, but I cannot find a design that I actually like. On @horriblename note on docs, it's not actually a concern because we can change the visiblity of the module to shallow and just provide the first level of attrs.

[sjcobb2022]

At least for the Vue module, I think the implementation that we have in #1322 could do with a little rework.

Perhaps providing vtsls, as a typescript server regardless, and then modifying the service with vim.lsp.servers would work.

Kinda like: vue.enable => vtsls.enable and vtsls.extraStuff = vueLangServer...

As an alternative, I have been thinking about the idea of mapping groups of configs instead of individual configs.

Roughly:

defaultServers = ["group1"]
servers = {
  group1 = {
    lsp1 = {
       # lsp1 config
    };
    lsp2 = {
      # lsp2 config
    };
  };
  group2 = {
    lsp3 = {
      # lsp3 config
    };
  };
};

If we are smart about it, we could define a type that is either an attribute set of lsp config, or an attribute set of attribute sets of lsp configs.

This would mean the API could look more like:

defaultServers = ["group1"]
servers = {
  group1 = {
    lsp1 = {
       # lsp1 config
    };
    lsp2 = {
      # lsp2 config
    };
  };
  lsp3 = {
    # lsp3 conf
  };
};

This is a very rough design, but it would allow us to do stuff like enable vtsls in a Vue module whilst keeping it relatively simple.

Just as an aside, for Vue at least, all we really want to do is enable languages.vtsls and then add it to the extra config section or whatever it's called.

Sorry for the long rant!

[sjcobb2022]

Just had a bit of a though on this, but if we go with this approach we could do something like:

defaultServers = ["vue"]
servers = {
  vue = {
    vuelsp = {
       # lsp1 config
    };
    vtsls = config.vim.lsp.servers.vtsls // { enable = true; } 
  };
};

But this implies that vtsls is already enabled for the config to be applied properly. Alternatively as you have proposed, store the configuration in some globally accessible (but only internally to the library) location such that we can set the value with a low priority by default.

I'm not sure your thoughts on this, but perhaps then changing the internal API to make all of the vim.lsp.servers be populated with the defaults, but disabled by default. Then we could follow what is said in this TODO so that we do not bloat the user's nix store.

Perhaps the "simpler is better" approach would be do simply do the split of this configuration into something like:

defaultServers = ["vue"]
servers = {
  vue = {
     # each has a lsp section where lsp stuff is configured
     lsp = {
        # vue lsp setup
     };
     # each has a language section that can be configured
     languages = {
        vtsls.enable = true;
        # do any more user-facing stuff here e.g. picking specific server for a language that is required for this specific LS to function.
     };
  };
};

And combined that with some mapping function that converts that into the right format.

EDIT: perhaps we could also add a tag to the lspOptions type called something like includeInConfig which defaults to whatever enabled is, but can be overwritten