[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Xref Fallback

From: Dmitry Gutov
Subject: Re: Xref Fallback
Date: Mon, 10 Aug 2020 22:01:34 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]