Re: Xref/tags/lsp possible bug

[Dmitry Gutov]

Hi!

On 23.04.2022 15:17, Alessandro Bertulli wrote:
> Hi all!
>
> I just stumbled upon a very strange behavior of Emacs, I don't know if
> it is a bug or an error of my configuration. Basically, I noticed two
> things:
>
> - First, when using LSP modes (both lsp-mode and eglot), the command
>    xref-find-definitions only acts on the symbol under point. I
>    explain: usually, in vanilla Emacs (emacs -q) if point is on a
>    whitespace/not on a symbol, invoking the command (bound to M-.) will
>    prompt you for an identifier to search for. However, when LSP is
>    active, it directly searches for an empty symbol, for example
>    reporting something similar to: "Symbol  not found" (not the double
>    space, which makes me think it searches for a symbol named ""). As I
>    said, this happend both for lsp-mode and eglot, so maybe is a
> problem of xref?

AFAIK it's a limitation of the LSP protocol: it's unable to perform 
completion on all symbol names globally. Nor is it able, in general, to 
find a symbol by name (it needs a location of an existing reference in 
some file). So that affects how lsp-mode's Xref integration works (and 
Eglot's).

> - Second, and minor: while I was investigating, I noticed that,
>    depending on the loaded packages, when giving M-., xref sometimes
>    asks for the symbol to search, sometimes it asks the TAGS table
> first. What package can be the problem?

ivy-mode, probably. Though it's not necessarily a "problem".

ivy-mode takes over the completing-read UI, and it tries to show the 
available completions right away. The identifier completion table 
provided by the default Xref backend uses tags, and when the table is 
not loaded, has to prompt for the file to load it from.