Bekaboo / dropbar.nvim

IDE-like breadcrumbs, out of the box
GNU General Public License v3.0
896 stars 17 forks source link

[Feature]: LSP priority list #145

Closed pidgeon777 closed 3 months ago

pidgeon777 commented 4 months ago

Problem

Sometimes, multiple LSP could be attached to a buffer.

My proposal is to add a LSP priority list, such as implemented by aerial.nvim:

    -- Map of LSP client name to priority. Default value is 10.
    -- Clients with higher (larger) priority will be used before those with lower priority.
    -- Set to -1 to never use the client.
    priority = {
      -- pyright = 10,
    },

https://github.com/stevearc/aerial.nvim?tab=readme-ov-file#options

Expected behavior

If one attached LSP server has an higher priority than the other ones, it should be used as LSP source.

Bekaboo commented 4 months ago

Why? Ideally, each buffer should have only one language server that provides 'textDocument/documentSymbol' method, which provides information on the syntax tree; additional language servers are usually responsible for providing other capabilities, e.g. diagnostics/formatting that have nothing to do with the symbols.

pidgeon777 commented 4 months ago

Thank you for your prompt response and for sharing your perspective. I understand the importance of having dedicated LSP servers for specific tasks within a buffer, as you mentioned. However, there are several scenarios where the ability to prioritize LSP servers can significantly enhance efficiency and user experience.

For instance, consider a development environment with multiple LSP servers that offer partial overlaps in functionalities, including the ability to provide document symbols. Although we ideally want to use a single server for 'textDocument/documentSymbol', in practice, there may be situations where one server provides more accurate or detailed results than others for certain languages or project types. Priority allows users to optimize this selection based on context.

Moreover, some projects might require integration with multiple frameworks or libraries, each better supported by a different LSP server. A priority mechanism would allow for dynamic selection of the most appropriate server based on the part of the project being worked on.

Additionally, adopting a priority list offers users the flexibility to experiment and customize their LSP setup based on their preferences and needs, without being constrained by a rigid assignment of responsibilities among LSP servers. This approach aligns with the philosophy of customization and user empowerment that characterizes many tools and plugins in the Neovim ecosystem.

It's worth noting that other plugins, in addition to aerial.nvim, implement a similar functionality, such as outline.nvim:

providers = {
  priority = { 'lsp', 'coc', 'markdown', 'norg' },
  lsp = {
    -- Lsp client names to ignore
    blacklist_clients = {},
  },
},

Clearly, an option to set priorities (as implemented in aerial.nvim) would be far more efficient than a simple blacklist.

I understand that implementing a priority feature may pose technical challenges, but I believe that the benefits in terms of flexibility and customization of the user experience justify exploring this possibility.

Bekaboo commented 4 months ago

@pidgeon777 Thanks for your reply. What is the real usecase? I need a concrete scenario instead of a possibility where this feature is useful.

FYI you can disable a language server's 'textDocument/documentSymbol' capability if you don't need it to provide symbol information, for example, if you are using nvim's builtin LSP client for lua files:

vim.lsp.start({
  cmd = { 'lua-language-server' },
  root_dir = -- ...,
  on_attach = function(client)
    client.server_capabilities.documentSymbolProvider = false
  end,
})