[Top][All Lists]

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

Re: xref-find-matches and stuff

From: Eli Zaretskii
Subject: Re: xref-find-matches and stuff
Date: Sat, 09 May 2015 16:19:36 +0300

> From: Vitalie Spinu <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Sat, 09 May 2015 14:32:03 +0200
>  >> > And my point is, the backends should be made well enough that you
>  >> > generally won't want to use a symbol from the 2nd backend that isn't
>  >> > in the first one. Ideally because there will be no such symbols.
>  >> 
>  >> I am afraid this is an impossible task.
>  > Can you tell why?
> In an ideal world you can imagine a tag-like backend that would know all
> possible language and would be aware of all the intricacies of multiple
> projects that you are working on simultaneously. It would also sniff
> through all open files and tag them automatically.
> Then, indeed, you won't need Imenu, nor REPL backends. Till such an
> universal tool is there, xref itself comes very close to it if imenu,
> tags and REPL backends were automatically merged.

If by "merged" you mean a union of all the symbols returned by all the
back-ends, then you have just described a single back-end that will
satisfy our needs.

>  > To me, this means we need to have a single back-end for each
>  > situation, and ideally also a mechanism to choose that single
>  > back-end automatically.  I see no reasons to conclude that we need
>  > more than one in each use case.
> Assume a high level language project with no good support for tags (R
> for example's sake) which uses C++. REPL backends can give you
> references only for loaded code in REPL, tags give you references only
> for C++. Imenu gives you references for all open C++ and R files. Your
> task is to jump from A to B (plot attached).

See above.

> You and other people seem to assume that given the context of A you can
> infer which backend to use in order to jump to B. Unless you you have an
> unique symbol at point in A matching B, that's impossible.

I'm sorry, but you didn't say what are A and B here, and what is the
context of A.

> If I am in an C++ tutorial which is not tagged (but has Imenu). Assume
> no symbol at point. How can xref know if I want to jump to a symbol in
> this example file (imenu backend) or a C++ file in my current project
> (tags backend)?

Who or what _can_ know that, except the user herself?  And the user
then has to set up this session so that the _single_ relevant back-end
is to be used.

And anyway, are the majority of the projects we work on tutorials?  I
sincerely doubt that.

> Dmitry goes as far as to suggest that even on C-u M-. only one backend
> should be completed upon. I just don't see that working at all. With
> multi-language projects it's common to have a high level wrapper (foo)
> for low level (C_foo) and you would want to jump back and forth from
> `foo` to `C_foo`. `C_foo` is probably unique, `foo` is not, and you just
> cannot disambiguate the backend only by current context. In R projects I
> can even have two different objects with the same name, one in C and one
> in R.

The difficulty of making the decision which back-end to use does not
imply that we should avoid making the decision.  It just implies we
need better methods of making that decision.  Avoiding the decision
makes no sense, it will just bring more chaos and confusion.

>   1) merge backends
>   2) select the backend before jump
>   3) assign each backend to a separate key
> IMO, the 3rd is better than the 2nd and I guess it's the current
> situation for loads of people.
> I have C-. for elisp-xref, M-. for whatever is the default, M-o for
> imenu-anywhere and I am seriously thinking about the forth key for etags
> because inconsistency with M-. started jarring on me.

There's a saying that a person with one watch always knows the time,
even if her idea of the time is a bit biased; whereas a person with
more than one watch always confused wrt what time it is.

reply via email to

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