Feature requrest: Override language LSP handler

[connorgmeehan]

Hi there,

Problem

I develop a lot of vue code projects and a new LSP has been developed called volar. There is a PR in the nvim-lspinstall repository that adds this LSP under the name volar. Because the LSP is not named the same as the language, it can't be installed automatically.

Proposal

Possible alternative api

    "vue +lsp", -- default LSP
    "vue +lsp(volar)", -- override LSP

This would be an optional override where install_servers uses the string within the brackets to select which LSP to install.

Consequences

We can expect these LSPs to conflict with eachother, if an override is supplied we should automatically uninstall the original LSP (if it is installed).
More opportunities for doom-nvim users to mess up their own config.
New non-standard API (doom-emacs doesn't have a similar setup).

I'm working on a PR now which I'll reference soon.

[NTBBloodbath]

Hi, this is a really cool feature, and this would allow us to extend our lsp functionality!

I think this alternative api syntax is pretty fine, totally agree with your idea about the implementation :)

Also this syntax could allow us to in a future also setup language servers that lspinstall doesn't cover (e.g. if the user wants to use other Python language server that he installed system-wide) and increase doom's extensibility IMO.

Just a quick note if you haven't read our contributing guidelines: since this isn't a bug fix you should target develop branch :)

Feel free to ask me something if you need help with the PR, I'll be glad to help you.

Regards

[connorgmeehan]

Thank you heaps for the support. I've just realised there may be cases where we want multiple language servers for the same files. For example tailwindcss which works on a range of files 😢.

Kind of a different use case and could be a different PR.

I was also thinking you could do something like this. Duplicating the html and css feels a bit weird but it's probably better than having two APIs. Also in this example the second tailwindcss is redundant but it shouldn't create any issues as we check if the LSP is installed before installing it.

    "html +lsp(html, tailwindcss)",            -- HTML support
    "css +lsp(css, tailwindcss)",             -- CSS support

[NTBBloodbath]

Hmm yeah this supposes a "change" of plans lol, we can introduce this in an additional PR.

Duplicating the languages names can feel a bit weird and even redundant, but this actually has a point and that's the important thing. This can be translated to "I want CSS support with the CSS and tailwind language servers" so maybe we can go with the approach that you've proposed in order to also avoid creating an additional API.

You can do the initial one that you've proposed at first instance and we can do this one later if you want to, it's better to take one step than to take none :p

[NTBBloodbath]

Huh this is still unresolved, don't you want this feature anymore? 👀

[connorgmeehan]

😵‍💫 Ooops, blanked on this, I forgot I didn't finish the PR my bad!

[NTBBloodbath]

No worries, was just asking :p