Xref Fallback

Xref Fallback

[Philip K.]

Hi,

a few weeks ago, I managed to port "dumb-jump"[0] to use Xref instead of
it's own custom interface[1]. Part of the transition was to deprecate
the old commands[2], that has lead to some complaints among
"lsp-mode"[3] users, because lsp-mode doesn't fall back on dumb-jump if
it has no results[4].

Part of the issue is that LSP's Xref activation function just returns
"'xref-lsp", the symbol that is specializes it's xref methods on,
without any checking -- which is fairly common from what I see. But if
that fails, Xref won't go on searching, even though the next backend
could have more to offer.

Before writing this message, I was fairly sure that there were some
discussions on this issue, but I couldn't find them in the archives
anymore, so just to be safe, I re-iterated the problem.

What I would want to know, is if there have been discussion on this
issue, what the status is, and if not what would have to be done. I can
imagine, that falling back onto the next backend isn't always desirable
(especially if etags is next, and it demands a TAGS file that doesn't
exist).

[0] For those unfamiliar, dumb-jump is a package for finding places
    where functions or variables are defined, but without any permanent
    external tools such as etags or indexing servers, but by using grep
    or grep-like tools and a search-database
    (https://github.com/jacktasia/dumb-jump).
[1] https://github.com/jacktasia/dumb-jump/pull/343
[2] https://github.com/jacktasia/dumb-jump/pull/349
[3] https://github.com/emacs-lsp/lsp-mode/
[4] https://github.com/jacktasia/dumb-jump/issues/353#issuecomment-671462247
[5] https://github.com/emacs-lsp/lsp-mode/blob/00fcee92ae2e57055fdb31d25741b9637fe96215/lsp-mode.el#L6174

Re: Xref Fallback

[Dmitry Gutov]

On 10.08.2020 20:10, Philip K. wrote:
> Part of the issue is that LSP's Xref activation function just returns
> "'xref-lsp", the symbol that is specializes it's xref methods on,
> without any checking -- which is fairly common from what I see. But if
> that fails, Xref won't go on searching, even though the next backend
> could have more to offer.
> 
> Before writing this message, I was fairly sure that there were some
> discussions on this issue, but I couldn't find them in the archives
> anymore, so just to be safe, I re-iterated the problem.

Some time ago Joao declared an intention to improve this (on the Eglot 
bug tracker), but that didn't have a follow-up.

> What I would want to know, is if there have been discussion on this
> issue, what the status is, and if not what would have to be done. I can
> imagine, that falling back onto the next backend isn't always desirable
> (especially if etags is next, and it demands a TAGS file that doesn't
> exist).

How would you feel about creating an xref backend that would implement 
the fallback logic? It would basically only do the combining, without 
having any navigation logic of its own.

This way users could include it in the xref-backend-functions to enable 
fallback mechanics. The said combinator backend could also hardcode some 
particular backends to skip.

Re: Xref Fallback

[Philip K.]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> What I would want to know, is if there have been discussion on this
>> issue, what the status is, and if not what would have to be done. I can
>> imagine, that falling back onto the next backend isn't always desirable
>> (especially if etags is next, and it demands a TAGS file that doesn't
>> exist).
>
> How would you feel about creating an xref backend that would implement 
> the fallback logic? It would basically only do the combining, without 
> having any navigation logic of its own.
>
> This way users could include it in the xref-backend-functions to enable 
> fallback mechanics. The said combinator backend could also hardcode some 
> particular backends to skip.

This sounds interesting, I'll try to get something like this
working. Would this be merged into Xref, or should it be a separate package?

Re: Xref Fallback

[Dmitry Gutov]

On 11.08.2020 21:19, Philip K. wrote:
> This sounds interesting, I'll try to get something like this
> working. Would this be merged into Xref, or should it be a separate package?

I'm fine with having it in Xref (as long as it's off by default).

It should be easier to discuss the details after we have something working.