LSP config (settings) interface

[justinmk]

Problem

Discussion in #23984 (comment) and other LSP work indicates we need a full story for configuring LSP clients...

1. globally ("default")
   • per-filetype
2. dynamically (on-demand)
   • for all clients attached to current buffer
   • for specific client?
3. per-buffer (this is low-priority, avoid much complexity to support this)

#22598 (comment)

Expected behavior

• vim.lsp.config : feat(lsp): add vim.lsp.config #18506
  • potential blockers:
    • should we adopt workspaceFolder instead of "root markers"
    • "multi-server" conflicts with per-server configs.
      • how far can we get with the "obvious" approach of per-server config?

Rejected ideas

• Flags in vim.lsp.start(), e.g. start({ ..., formatting = false, semantic_tokens = false, inlay_hints = true, ... })
  • Why: LSP has tons of configuration, so start() flags are not sufficient.
• vim.lsp.start({capabilities={...}})
  • Why: un-declaring client capabilities is probably too hacky?
  • Related: Disabling a LSP capability #24058

[T-727]

This is probably too big of a rework and/or doesn't work as well as it does in my head, but it's interesting to think about imo so I'll throw it out here:
What if instead of using lua wrappers you used the vim option + variable systems 🤔

[glepnir]

should we adopt workspaceFolder instead of "root markers"

also need consider file is library file. in this case usually need attach to a exist client . provide a field islibrary function type to validate fname is library or not is needed

[mfussenegger]

flags in vim.lsp.start(), e.g. start({ ..., formatting = false, semantic_tokens = false, inlay_hints = true, ... })

It could also be an option to overload those to boolean|table. Then you could still disable the functionality with <option> = false, or enable it with its defaults with <option> = true, but also have more granular control if needed. For example semantic_tokens = { debounce = 500 }

Although this would still only address the "per client" (static) configuration.

---

Regarding vim.lsp.config:

should we adopt workspaceFolder instead of "root markers"

I think this is a bit of a red herring. We've lsp.start and lsp.start_client both which support setting workspaceFolders. To use more than one workspaceFolders you always need some heuristic to make that decision and you need to know that the language server actually supports it in a meaningful way (many don't). So imho this is out of scope for core, and unrelated to having a global configuration skeleton. (What we could do is extend vim.lsp.start to automatically extend the workspaceFolders if reuse_client returns true, to make it easier to use)

I think if we do a vim.lsp.config, it should act as a template/skeleton for vim.lsp.start - basically take care of the "global" part, while the config argument of vim.lsp.start takes care of the per-client settings.

[justinmk]

So imho [workspaceFolder instead of "root markers"] is out of scope for core, and unrelated to having a global configuration skeleton. (What we could do is extend vim.lsp.start to automatically extend the workspaceFolders if reuse_client returns true, to make it easier to use)

I think if we do a vim.lsp.config, it should act as a template/skeleton for vim.lsp.start - basically take care of the "global" part, while the config argument of vim.lsp.start takes care of the per-client settings.

Nice. So #18506 is unblocked @gpanders