Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatically install servers when explicitly called by lspconfig[server].setup {} #44

Open
Kruziikrel13 opened this issue Jun 14, 2024 · 5 comments

Comments

@Kruziikrel13
Copy link

Like the automatic_installation option in mason-lspconfig.

Instead of lazy loading on file types. Lazy load on lspconfig server calls.

@dundalek
Copy link
Owner

Could you share more details, do you have a specific use case in mind? Are you perhaps trying to integrate with some specific plugin or something like that?

@Kruziikrel13
Copy link
Author

Kruziikrel13 commented Jun 17, 2024

Yep, I'll try and demonstrate below...

The most pertinent reference being in mason-lspconfig here under the setup option of automatic_installation

This means that whenever I call / attempt to setup a language server via lspconfig... it will be automatically installed if it wasn't already. E.g.

require('lspconfig').lua_ls.setup {}

Will result in lua_ls being automatically downloaded and installed.

In my particular use case I setup my lsp's manually and at a project level instead of from the neovim configuration level. I do this using the local_spec file functionality from lazy.nvim (.lazy.lua)

e.g. my setup for loading lua_ls when I'm working on my neovim configuration
image

note: setupLspServers is just a wrapper around with some extra stuff require('lspconfig')[lang_srv].setup{}

Key point being, I do my language server setup manually and at a project level rather than at the neovim config level. The ability to just have the servers installed when called via lspconfig would be pretty neat I think.

Of course I could just use mason but it's a bit heavy imo, I really just need the ability to auto install prior to my lspconfig call running.

@dundalek
Copy link
Owner

Great explanation, I think I understand now. It seems we want to be able to setup servers individually.

This is a bit different that the original intent of the plugin, adding an option to existing API would multiply complexity. I am leaning towards introducing an additional API.

I am thinking we could have something like require('lazy-lsp')[lang_srv].setup{} to setup an individual server (or perhaps require('lazy-lsp').lspconfig[lang_srv].setup{} to avoid potential future function name clashes). When using this function one would not call require('lazy-lsp').setup{} at all. Do you think that would cover your use case?

Next there is the question if we should hook into lspconfig and support the require('lspconfig')[lang_srv].setup{} form. Personally I don't like plugins that do that, it makes things more brittle and less composable. It seems mason-lspconfig uses on_setup hook. I wonder if it would make sense to have a something like a on_setup function? Then one could configure it like:

local lspconfig = require 'lspconfig'
lspconfig.util.on_setup = lspconfig.util.add_hook_before(lspconfig.util.on_setup, require('lazy-lsp').on_setup)

With that the require('lspconfig')[lang_srv].setup{} should work. Is it worth the extra complexity?

@Kruziikrel13
Copy link
Author

Kruziikrel13 commented Jun 20, 2024

Ah! There is a hook! That is quite useful! I think this could be done a few ways...

You could have the option for 'automatic_installation' much like mason... Or you could even just have a 'recipe' / wiki entry explaining how to setup that functionality for any who would want it.

The extra function approach also works! Though I think with that approach it may be pertinent to add an option to disable auto installation / setup on file types to allow users to do their setup explicitly... perhaps that's an option just worth adding for both approaches. (The ability to disable auto setup on filetypes)

@dundalek
Copy link
Owner

Another idea that came to mind would be to always register the hook.

Then current functionality would be preserved be iterating through all servers and calling setup on them. We could have something like auto_setup option that could be set to false and then one could call setup for individual servers manually.

If we always register the hook it might also be feasible to solve the curated servers setup (#23). We could have auto_setup take values

  • all to setup all servers
  • curated for only curated (but thanks to the hook calling setup manually would also enable fetching from nix-shell)
  • none - one needs to call setup for each server individually

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants