cordx56/rustowl

[Neovim] remove hard dependency on lspconfig

Closed this issue · 3 comments

What is the problem you're trying to solve

  • I don't use nvim-lspconfig, but would like to be able to use the rustowl neovim plugin.
  • I'd like rust-related plugins I use to be initialised only when I open a rust file.
  • Someone has requested that I add support for rustowl to rustaceanvim, because it "nicely configures everything for an out of the box experience.".
  • nvim-lspconfig is meant to be 'a "data only" repo'.
  • In Neovim's built-in startup sequence (which lazy.nvim overrides, but most plugin managers rely on), plugin scripts are sourced after init.lua. So the lspconfig.rustowl configuration that is added in this plugin's script won't be available yet, breaking the current rustowl Neovim plugin for non-lazy.nvim users.

Describe the solution you'd like

I think it would be quite easy to remove the lspconfig dependency (or make it optional in case someone prefers to use it) and to modify the rustowl plugin to work out of the box, like rustaceanvim (I'd be happy to work on this if there's interest).

My proposal:

  • Add a ftplugin/rustowl.lua script that lazily starts the rustowl LSP client automatically when triggered by a rust file being opened, without any setup needed by users.
  • Use a vim.g.rustowl table and/or a setup function for user configuration (e.g. trigger and auto_attach)
    The benefit of a vim.g table is that the plugin can be configured without having to require a Lua module at startup.
  • You can also use this logic to check if a rustowl lspconfig configuration has been setup without needing to require the lspconfig module, and if so, prevent the LSP client from attaching in the ftplugin script.
  • You can leverage the LspAttach autocommand to invoke rustowl_on_attach.
  • The lspconfig.util functions you use can be replaced with built-in Neovim API calls.

Additional context

Potential downside: This may increase the minimum required Neovim version.

Thank you for your proposal.
There is a PR #48 that improve nvim plugin now and I'm reviewing it.
So I will work on this proposal after the PR is merged. (or you can join the discussion)

@mrcjkb is this fixed in #48 ?

Yes.