Re: Adding support for xref jumping to headers/interfaces

[João Távora]

On Fri, Mar 10, 2023 at 9:55 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 10/03/2023 02:57, Ergus wrote:
> > Ho Dmitry and Joao
> >
> > On March 6, 2023 3:09:40 PM GMT+01:00, Dmitry Gutov <dgutov@yandex.ru> 
> > wrote:
> >> On 06/03/2023 01:40, John Yates wrote:
> >>> For languages that do not distinguish declaration from definition,
> >>> another alternative is to have both key bindings reference the same
> >>> find-definition functionality.
> >
> > Yes please, just fall back to find-definition (or find-references) + a 
> > warning when find-declaration or the the others are not supported? It is 
> > simpler and practical.
>
> Could you explain this usage scenario? Why not just report "unsupported"
> and let the user try again with the simpler key binding (M-.)?
>
> It's not like people will prefer to reach for C-M-?, or will hit it by
> accident.

I haven't been following this discussion very closely for the last
few days, but last I followed it, we were on the M-x xref-find-extra
idea of Felicián. There -- at least as far as i understood -
Dmitry's idea was to ask the xref backend what kind of syntactic
constructs  it supports finding, say via some xref-extra-constructs
generic function.

Eglot would have an answer for that, and so could other backends
like etags, SLY,  and any other backend presumably.  Xref could
then keep track of who supports what and the M-x xref-find-extra
would ask those backends for those things that they support.

I think this would be a pretty good idea to avoid the concept
creep problem and still provide a nice user interface.

So, unless we are talking about the case were absolutely 0
"extras" are supported in M-x xref-find-extra. I don't get the
fallback idea nor the "unsupported" message idea.  The problem
would simply not exist.

João