languages: expose low-level API; convert existing modules

[NotAShelf]

Based on the feedback collected from https://github.com/NotAShelf/nvf/discussions/748, and other online spaces, this pull request exposes a low-level vim.lsp.servers API that will be consumed internally by language modules, in a way that allows no-overhead LSP setups for both this project and end-user setups. This is, in short, the long-awaited language moduler refactor.

The new API can also be used to override LSP options set by language modules, on top of setting up LSPs not supported directly by nvf. In addition, the language modules now take a list of servers to allow supporting multiple servers with ease (relevant: #575)

Modules not converted:

• [ ] Nix
• [ ] Scala
• [ ] Rust

Breaking Changes

1. vim.languages.rust.crates.enable has been renamed to vim.languages.rust.extensions.crates-nvim.enable

[github-actions[bot]]

:rocket: Live preview deployed from 79993c71d88d7bfafc1ae029bd9621cd74e1529d

View it here:

Debug Information

Triggered by: horriblename

HEAD at: lsp-redesign

Reruns: 851

[thamenato]

@NotAShelf I was wondering about submitting a PR adding setupOpts to Python's LSP to allow changing the default settings - I noticed some other plugins/modules do that and thought that'd be the way to do it here as well (I don't know if there's already a way).

In any case, should I wait until you get this PR merged before working on it, or start the work based on this branch?

Tks!

[NotAShelf]

@NotAShelf I was wondering about submitting a PR adding setupOpts to Python's LSP to allow changing the default settings - I noticed some other plugins/modules do that and thought that'd be the way to do it here as well (I don't know if there's already a way).

In any case, should I wait until you get this PR merged before working on it, or start the work based on this branch?

Tks!

Sorry for not replying earlier @thamenato , I completely missed your comment somehow. setupOpts is not really intended for language modules, as they do not have a direct equivalent like .setup(). The new API that we're working on top of provides all fields, and I'd encourage you to use it instead as vim.lsp.servers or the new languages.*.lsp.settings option.

[sjcobb2022]

Hi @NotAShelf,

I've started reviewing the details of this ticket, and I wanted to clarify a few points regarding the current state of the core API. I had some questions about the API design and configuration intent that I'd appreciate your input on.

Questions on lsp.settings

Could you clarify where the languages.*.lsp.settings mentioned in your previous comment is defined? I'm not seeing it in the current codebase—wondering if it's missing or located elsewhere.

API Design Clarifications

Is the intention of this ticket to define a fixed set of supported LSPs that users cannot customize?

From the current implementation, it appears the user cannot define their own server. If I'm interpreting the design correctly, the envisioned usage looks something like:

languages.rust = {
  enable = true;
  server = ["rust-analyzer" "anotherLSP"];
};

While I understand the intent to simplify configuration, this approach seems quite restrictive. Do you foresee the ability to configure LSPs in a more flexible way in the future?

When I initially started exploring this ticket, I had imagined something closer to:

languages.*.server = mkOption {
  type = listOf (attrNames lspOptions);
};

I think a compromise between the two approaches could also work:

type = listOf oneOf [
    (attrNames lspOptions)
    (attrNames servers)
 ];

That said, I also understand this might not align with the core principles of nvf configuration. Would appreciate your thoughts on whether more flexibility is in scope or if the current direction is intentional.

Thanks!

[horriblename]

this PR is superseded by #860

the new implementation uses neovim 0.11's vim.lsp.config, and is as flexible as it gets

[github-actions[bot]]

✅ Preview has been deleted successfully!