all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Xref Fallback
@ 2020-08-10 17:10 Philip K.
  2020-08-10 19:01 ` Dmitry Gutov
  0 siblings, 1 reply; 4+ messages in thread
From: Philip K. @ 2020-08-10 17:10 UTC (permalink / raw)
  To: emacs-devel


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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Xref Fallback
  2020-08-10 17:10 Xref Fallback Philip K.
@ 2020-08-10 19:01 ` Dmitry Gutov
  2020-08-11 18:19   ` Philip K.
  0 siblings, 1 reply; 4+ messages in thread
From: Dmitry Gutov @ 2020-08-10 19:01 UTC (permalink / raw)
  To: Philip K., emacs-devel

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.



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Xref Fallback
  2020-08-10 19:01 ` Dmitry Gutov
@ 2020-08-11 18:19   ` Philip K.
  2020-08-11 18:51     ` Dmitry Gutov
  0 siblings, 1 reply; 4+ messages in thread
From: Philip K. @ 2020-08-11 18:19 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: emacs-devel

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?



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Xref Fallback
  2020-08-11 18:19   ` Philip K.
@ 2020-08-11 18:51     ` Dmitry Gutov
  0 siblings, 0 replies; 4+ messages in thread
From: Dmitry Gutov @ 2020-08-11 18:51 UTC (permalink / raw)
  To: Philip K.; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-08-11 18:51 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-08-10 17:10 Xref Fallback Philip K.
2020-08-10 19:01 ` Dmitry Gutov
2020-08-11 18:19   ` Philip K.
2020-08-11 18:51     ` Dmitry Gutov

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.