Re: xref-find-matches and stuff

[Vitalie Spinu <spinuvit@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]

 >>> Eli Zaretskii on Sat, 09 May 2015 11:05:31 +0300 wrote:

 >> > 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.


 >> - IMENU operates on what I work, is always up-to date, works with
 >> non-programming modes (org, latex etc), non-visiting buffers
 >> (*scratch*) and any project-less file/language what I might open for
 >> whatever cursory reason. Stuff works out of the box - no tagging, no
 >> REPL is required.
 >> 
 >> - REPLs are good, but work only on loaded files. Usually these cannot
 >> work with multiple projects or multi-language projects. Cross
 >> references support is lacking for many REPLs.
 >> 
 >> - TAGs can support multiple projects but cannot do what Imenu can and
 >> will never be as smart as REPLs can be. No support for less common
 >> languages. Limited UI in emacs is a hindrance for common users (I
 >> cannot comment about ggtags though).

 > 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).


[-- Attachment #2: xref.png --]
[-- Type: image/png, Size: 6111 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1382 bytes --]


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.

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)?

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.


There are basically three ways out

  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.


  Vitalie