"[eglot] cannot (yet) provide reliable completion table for LSP symbols"

[garyo]

I'm using latest eglot, and when I do C-u M-x xref-find-definitions, which normally (without eglot) prompts for a symbol to find definitions for, instead I get this error message: "[eglot] cannot (yet) provide reliable completion table for LSP symbols", and then it returns to toplevel so I can't search for my desired symbol.

Here's the backtrace:

Debugger entered--Lisp error: (error "[eglot] cannot (yet) provide reliable completion t...")
  signal(error ("[eglot] cannot (yet) provide reliable completion t..."))
  error("[eglot] %s" "cannot (yet) provide reliable completion table for...")
  eglot--error("cannot (yet) provide reliable completion table for...")
  (progn (eglot--error "cannot (yet) provide reliable completion table for..."))
  (closure (revert-buffer-preserve-modes t) (_backend) (progn (eglot--error "cannot (yet) provide reliable completion table for...")))(eglot)
  apply((closure (revert-buffer-preserve-modes t) (_backend) (progn (eglot--error "cannot (yet) provide reliable completion table for..."))) eglot nil)
  xref-backend-identifier-completion-table(eglot)
  xref--read-identifier("Find definitions of: ")
  byte-code("\300\301!C\207" [xref--read-identifier "Find definitions of: "] 2)
  call-interactively(xref-find-definitions nil nil)
  command-execute(xref-find-definitions)

[joaotavora]

Well, the message is telling you how it is! :-D

LSP doesn't allow this, and Eglot can't do anything about it. @dgutov is aware of this, I think.

[joaotavora]

LSP doesn't allow this, a

OK, to be fair, it doesn't allow a reliable way to do this. There are some ugly workarounds, but they don't work like normal xref is supposed to.

[garyo]

I see. Is there any way to just make it not fail there, so I can just type any identifier (without completions)? Perhaps this isn't an eglot question but more an xref question, for @dgutov perhaps.
It's a bit frustrating that eglot/xref can find definitions of the identifier at point, but won't let me type in an identifier. Sometimes if I'm really stuck I just type the name into the buffer and then do M-. on it. I can follow up elsewhere if that's appropriate.

[joaotavora]

so I can just type any identifier (without completions)?

Eglot doesn't have anything reasonable or consistent to do with whatever you type there, so it's best that it fails.

I understand the frustration, though. Curiously, this is closely related to an issue opened just now too, #507. That is requesting the same but for documentation, not definition.

As I said, there are some workarounds like a workspace/symbol method that some servers support. But it's not easy to get a completion list of all symbols in the project. LSP works a lot by context.

[garyo]

I see -- you're saying the LSP server can only look up definitions for an identifier in the document, but has no way to look up a string. Sad, but makes sense I guess.

[joaotavora]

Let's reopen this: a recent development in LSP 3.15 is the opening I have been waiting for: See microsoft/language-server-protocol#1033

Now the hard work has to be done. Make a completion table based on workspace/symbol and somehow make it work with partial results. Nothing I haven't done before, but not trivial. Then you should be able to do what you want @garyo

[dgutov]

I've actually been meaning to suggest this. But there are pitfalls.

Not every LS supports it, and when they do, support varies. For instance, elixir-ls uses its own custom-defined prefixes to search for anything but types: https://github.com/elixir-lsp/elixir-ls#workspace-symbols. And it only supports inputs 3 characters or longer. Something to discuss with them, I suppose.

In any case, something would still need to be done if the server doesn't support this capability.

[joaotavora]

Not every LS supports it, and when they do, support varies.

This is the story of LSP. There are normally "capability" flags to control this, but I haven't checked here. It should allow us to carefully support incrementally and gracefully degrade. We should find a "good" server that implements this fully and perfectly and a "crappy" server that doesn't :-)

[dgutov]

We should find a "good" server that implements this fully

Try ccls, it does have a more conforming implementation.

[dgutov]

The new specification seems to be propagating nicely:

castwide/solargraph#328
golang/go#33844

[joaotavora]

@dgutov: If you want to propose changes to Eglot to support this, go ahead. I don't have time to tackle this particular problem right now. You can of course propose changes to xref.el and eglot.el in tandem:

• For old servers, Eglot would work like it does now.
• For new servers, a new completion table based on workspace/symbol

We must still somehow acommodate for the fact that the "identifier at point" may simply in the space that workspace/symbol gives us. So M-. for arbitrary identifiers is still out, I think.

[dgutov]

If you want to propose changes to Eglot to support this, go ahead. I don't have time to tackle this particular problem right now.

If I get to it, when I get to it. Not right this moment either, sorry.

Just collecting the relevant information here.

We must still somehow acommodate for the fact that the "identifier at point" may simply in the space that workspace/symbol gives us. So M-. for arbitrary identifiers is still out, I think.

Of course. But that's something the user will be made aware of through practice: not all symbols are available. "Why?" "You can ask the authors of the language server you are using".

The main difficulty is defining a symbol completion table that allows choosing the symbol at point (and retains the info that it's not just an arbitrary symbol), or any symbol from workspace/symbols.

[garyo]

As an alternative, would it be possible for xref.el (and/or eglot) to fall back to a manually constructed tags table? Just a suggestion.

…

On Wed, Jul 1, 2020 at 4:29 PM Dmitry Gutov ***@***.***> wrote: If you want to propose changes to Eglot to support this, go ahead. I don't have time to tackle this particular problem right now. If I get to it, when I get to it. Not right this moment either, sorry. Just collecting the relevant information here. We must still somehow acommodate for the fact that the "identifier at point" may simply in the space that workspace/symbol gives us. So M-. for arbitrary identifiers is still out, I think. Of course. But that's something the user will be made aware of through practice: not all symbols are available. "Why?" "You can ask the authors of the language server you are using". The main difficulty is defining a symbol completion table that allows choosing the symbol at point (and retains the info that it's not just an arbitrary symbol), or any symbol from workspace/symbols. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#506 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABCFRYB2EPJO7OX6PTS6U3RZOMDJANCNFSM4OHIQGDA> .

-- Gary Oberbrunner Founder & CEO Dark Star Systems, Inc <https://darkstarsystems.com>.

[joaotavora]

The main difficulty is defining a symbol completion table that allows choosing the symbol at point (and retains the info that it's not just an arbitrary symbol), or any symbol from workspace/symbols.

Something like that, yes. If you're into vc-region-history archeology, you will see that I had something like that setup earlier, but with symbols from the document. It was hacky, but didn't work horribly. It should be possible to do properly with workspace/symbol and text properties.

[mohkale]

@joaotavora

Okay I've recently been experimenting with consult-lsp and I've adapted it to work with eglot as well. It uses the same workspace/symbols method as we intend to do here so I think I can work on this issue as well now, I'm just not sure where the documentation for writing xref backends is so I'm hoping you could point me in the right direction.

Also could you open the wiki so that I can share my consult-eglot-symbols config. Here's what it looks like in action.

Also here's a screenshot because asciinema doesn't do justice to true color terminals.

[joaotavora]

Okay I've recently been experimenting with consult-lsp and I've adapted it to work with eglot as well. It uses the same workspace/symbols method as we intend to do here so I think I can work on this issue as well now, I'm just not sure where the documentation for writing xref backends is so I'm hoping you could point me in the right direction.

@dgutov is the xref expert and maintainer. You can work with him to recover context in this issue and try to solve it according to #506 (comment)

[dgutov]

The documentation: https://github.com/emacs-mirror/emacs/blob/7c901d90e620b4d3651b86c13faf1e81eeb3db10/lisp/progmodes/xref.el#L33-L40

🤷‍♂️

[joaotavora]

🤷‍♂️

That's what it is indeed, but may be a bit dry for beginners. @mohkale make sure you understand the problem first and then look at Eglot's existing xref backend. Then maybe try to write (failing) automatic tests for what you'd want to do with the new thing. Then show those tests. If we agree on the spec, you work to make them pass.