Later, a better resolve mechanism may be implemented to resolve these, if needed.

What would be a way to do it ? How does VS Code extension for rust analyzer implement it ?

Unfortunately, I have no good pointers at how VSCode does this, but in case of Zed we are doing a mixture of two approaches:

• first, we have tried to resolve all that's possible, spawning an async resolve task for all visible menu entries and whatever got selected later, if the user moves along the completion menu entries
• but it turned out that this either introduced certain latency or extra code complexity

I believe VSCode follows the complexity path, by trying to cache as many menu items as possible while the user types, predicting what has to be edited: e.g. Ha and HaMa might both replace the input with HashMap (+ add some global import edits, etc.) but it's the LSP which says that to replace (Ha and HaMa) to HashMap so it's some sort of predicting the LSP response.
This way, the resolve requests are relatively ready by the time the user asks for autocomplete.

We went with a simpler thing by re-querying the completion lists always, which lead us to excessive resolve queries — and even for the simple cases those were not instant, so there were noticed situations when a user may type and ask for autocomplete, which will take extra, very visible, fractions of second to execute due to resolve request + potential docs parsing took a while.

• resolving everything also causes visual flicker, as details may contain rich text for the completion label, while regular, unresolved completion just has its plaintext label.
  If we were to resolve the entire item menu (menu item height number of resolve requests to make each time), that would look somewhat slow to appear.
  If we were to show the menu instantly, it will "jump" into colors some time later.

So, after trying various resolves, we've ended up using VSCode's resolve set in Zed: we force LSP servers to send us everything needed for the menu to be colored and ready to complete something useful at the caret position instantly.
This means resolving docs, detail and additional text edits only.

The server is faster to compute these properties in bulk (instead of menu item height number of resolve requests to make each time) and the editor can complete things almost instantly, with the additional text edits applied in the background, asynchronously. Those are usually imports, so at least for Rust this works quite well.

Sorry, I'm not a Lisp person and do not understand what is wrong with the tests.
In fact, I cannot even compile the project on my vacation device right now, so I will not be able to fix them this week at least and appreciate some help.

Thanks for the detailed explanation!

This means resolving docs, detail and additional text edits only.

I guess with your change (in lsp-mode) we are still not resolving additional text edits ?

do not understand what is wrong with the tests.

They are just Emacs snapshot tests that are failing (which is expected). @jcs090218 Probably worth disabling tests in snapshot ?

I guess with your change (in lsp-mode) we are still not resolving additional text edits ?

I suspect some odd things may be there based on the issue comments, but I'm not familiar with the codebase enough to say that.

It seems though, that r-a works in lsp-mode in cases when imports are added through autocompletion.
With the broken version, now, when you complete the HashMap, nothing happens, but after this fix imports appear again.

I guess with your change (in lsp-mode) we are still not resolving additional text edits ?

We already support resolving additional text edits and also documentation property as well.
The only one that isn't supported now is detail. Actually if you enable company-auto-update-doc, you can observe that after moving the selection, the detail will show up on the previously selected item.

Also, instead of disabling detail resolve, we can actually resolve it asynchronously without affecting the latency for candidate list to show up.
See #4610

They are just Emacs snapshot tests that are failing (which is expected). @jcs090218 Probably worth disabling tests in snapshot ?

It's still quite confusing, but we have the experimental flag on (see below).

FYI, @kiennq is working on fixing in #4612. And I will push more fixes when I have time. :)