Re: Xref Fallback

[Dmitry Gutov <dgutov@yandex.ru>]

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.