Hi,
For context: I am currently learning about LSPs, because I am migrating from a VSCode to a NeoVim setup. I am working in an old codebase, where I need to get range formatting set up, since I often need to change small parts of legacy files without polluting diffs. Range formatting used to work for me in VSCode, but now that I am switching editors, I had a hard time turning the documentRangeFormatting capability on rust-analyzer on in NVim, and having it actually carry out the range formatting.
Initially, my entire rust-analyzer config was sent through the workspace/didChangeConfiguration LSP Call (with the config in the initialize call being empty), but this failed to activate the documentRangeFormattingProvider capability when the LSP came up. (NOTE: I did not manually do this, a neovim plugin called lspconfig did this for me, but this is what I observed in the logs).
I made some changes to have the relevant rustfmt.rangeFormatting.enable = true option sent as part of the initialize LSP request instead, and lo and behold, the LSP came up with documentRangeFormattingProvider enabled! However, range formatting still did not work, as I got the following well-known error message:
[DEBUG][2024-05-25 19:45:52] .../vim/lsp/rpc.lua:408 "rpc.receive" { error = { code = -32600, message = "rustfmt range formatting is unstable. Opt-in by using a nightly build of rustfmt and setting `rustfmt.rangeFormatting.enable` to true in your LSP configuration" }, id = 12, jsonrpc = "2.0"}
I hence set up my NVim plugin to send rustfmt.rangeFormatting.enable both during init and when changing the configuration, and this worked! However, this makes me wonder if I should be moving some of my other settings to init-time rather than config change time, and whether this somewhat strange duplicated workflow is a well-known issue.