Completion resolve support with textEdit

[traviscross]

Thank you for the bug report

• I am using the latest version of lsp-mode related packages.
• I checked FAQ and Troubleshooting sections
• You may also try reproduce the issue using clean environment using the following command: M-x lsp-start-plain

Bug description

This PR in rust-analyzer triggered a set of behavior regressions when using Emacs and lsp-mode:

• internal: Send less data during textDocument/completion if possible rust-lang/rust-analyzer#18167

On the r-a side, there is discussion to the effect that lsp-mode (and other editors) may be less spec-conformant than desired. See these comments and related issues:

• Make LSP completions resolve capabilities more spec-compliant #4609
• No signatures shown in completion popup rust-lang/rust-analyzer#18504
• Completion resolve support with textEdit #4607 (comment)
• Make LSP completions resolve capabilities more spec-compliant hrsh7th/cmp-nvim-lsp#75
• Auto-imports not working in Kate rust-lang/rust-analyzer#18363

This issue is opened in the hope that, in connecting here the experts on each side, that some agreement and resolution may be reached.

cc @jcs090218

Steps to reproduce

N/A.

Expected behavior

N/A.

Which Language Server did you use?

lsp-rust

OS

Linux

Error callstack

No response

Anything else?

No response

[kiennq]

lsp-mode already support, can you try to lsp-toggle-trace-io to see if the ‘completionItem/resolve’ is sent in your case? When I tried it already worked though

[traviscross]

Thanks for having a look. After further analysis, the r-a developers decided this was in fact a bug in rust-analyzer:

• Auto-imports not working in Kate rust-lang/rust-analyzer#18363 (comment)

[SomeoneToIgnore]

There seems to be another bogus issue created: rust-lang/rust-analyzer#18504
Which seems to be very related to the spec interpretation, based on #4591 OP:

Removing "documentation" + "detail" from
....

and

Can you try to move to the next item in the completion list to see if the function detail will be displayed for the previously selected item?

does not have an effect; details are not shown

change, that this part is not really resolved properly in lsp part of Emacs.

So, this issue is still technically relevant, but not correctly composed?

[traviscross]

OK. Reopening on that basis.

[SomeoneToIgnore]

To add on top, I think that the OP nails it: for now, one has to remove

"documentation" + "detail"

from the resolve capabilities to fix the things.

Before, r-a responded with both fields despite the capabilities, now it's more spec-compliant, which that causes issues on the client side.
Removing the corresponding resolve capabilities will restore the status quo, and more clever approach may be implemented later.

[kiennq]

The completion resolve with extra edit is already supported. If you have some example where it doesn't work, I would like to try it to see why.
Here is the working case in my env

[traviscross]

Note there are two issues here:

The first was about automatically importing items. This was reported here:

• Auto-imports not working in Kate rust-lang/rust-analyzer#18363

And was then fixed on the r-a side here:

• Use completion item indices instead of property matching when searching for the completion item to resolve rust-lang/rust-analyzer#18503

So this will work properly with r-a nightly (due to the fix) or in the Rust r-a distributed with Rust 1.82 (because that is before the change was introduced).

(If you want to see this problem, test with commit rust-lang/rust-analyzer@950bb83.)

The second item is about failing to display the details of method signatures. This is tracked on the lsp-mode side here:

• rust: no details in completion popup #4591

And on the r-a side here:

• No signatures shown in completion popup rust-lang/rust-analyzer#18504

This issue is present in r-a nightly and is not fixed by the other change. This is not present in the r-a distributed with Rust 1.82, so you'll need to test with nightly to see the problem.

Details for reproducing this result in a clean environment are described here:

rust-lang/rust-analyzer#18504 (comment)

It's been reported that eglot is not affected by this. I.e., that it continues to show full method signatures.

This issue is filed separately to track the general item about specification conformance potentially related to both issues that has been described by @SomeoneToIgnore above. Both these regressions were prompted by the same PR on the r-a side here:

• internal: Send less data during textDocument/completion if possible rust-lang/rust-analyzer#18167

[kiennq]

The resolve for detail (signature) should be supported in #4610
Before that, if you enable company-auto-update-doc it should be able to show the detail on-demand, after the item is focused.

[wyuenho]

WRT to textEdit, rust-analyzer still returns textEdit from the response in textDocument/completion, both for stable and nightly. We can close this ticket and focus on #4591, perhaps file a bug on rust-analyzer, once there's an agreement over there, and can perhaps roll back #4610 as neither insertTextMode nor insertTextFormat need to be resolved judging by the current state of affairs.