add documentFormattingProvider to server capabilities response

[williamboman]

Hey! Seeing as this LSP does support the textDocument/formatting command - I figured we could add it to the server capabilities response. Currently struggling to get neovim's LSP client to recognize the fact that the ESLint LSP server does in fact support formatting - this ought to fix it.

[dbaeumer]

The LSP server does register a document formatter provider but in a dynamic way. This ensures that if the formatter gets disabled ESLint formatter will not show up in the list of default formatters. Does NeoVim not support dynamic registration?

[sassanh]

Related: neovim/neovim#13634

[mjlbach]

We have not implemented dynamic registration in neovim. Most of the time users are setting up options declaratively in their init.vim/init.lua, so it hasn't yet made sense to enable dynamic registration for anything.

[sassanh]

Thanks! For those who don't know how to enable/disable features in their init.vim/init.lua, I did it by adding something like this to on_attach callback provided in server:setup:

local on_attach = function(client, bufnr)
  if client.name == 'tsserver' then
    -- Disable formatting for typescript
    client.resolved_capabilities.document_formatting = false
    client.resolved_capabilities.document_range_formatting = false
  elseif client.name == 'eslintls' then
    -- Enable formatting for eslintls
    client.resolved_capabilities.document_formatting = true
  end
  ...

It is working as expected, I just learnt this imperative way, I don't know about the declarative approach yet.

[dbaeumer]

Go, great to hear that this exist. I will close the PR then since the servers recommended way is to have dynamic registration.

[williamboman]

Thanks everyone for jumping in! Apologies if I'm continuing the discussion in the wrong repo, but @mjlbach would you say the snippets @sassanh provided is the recommended way to "toggle" the registered capabilities of LSP clients (e.g., disable document formatting for client #1, but enable it for client #2)? If yes, do you recommend doing so as @sassanh has done it, in the on_attach callback and reading the client.name property?

[williamboman]

Also a question for @dbaeumer: For ESLint LSP - would you say that the source.fixAll{.eslint} code action request is fully synonymous with the textDocument/formatting request, and both can safely be used interchangeably? Or do you see these potentially drifting apart in the future?

[dbaeumer]

source.fixAll{.eslint} and textDocument/formatting might already today not produce the same result. So they are not interchangeably.