Re: xref-find-matches and stuff

[Dmitry Gutov]

Sorry, we seem to be talking past each other. The bit about etags and 
unames (which makes having merge a part of the core behavior difficult) 
felt particularly relevant to me.

The question I'm trying to answer is what behavior would suit an average 
user best, and that doesn't involve manual management of backends, IMO. 
You can still implement a merging backend on top of it.

Using one backend at a time would mirror the mechanics of 
completion-at-point-function, which have been easy to comprehend for 
major mode authors thus far (just use `add-hook'). Asking a major mode 
to make a decision whether it will augment their results with etags, 
seems improper. But else to do that, if the value is a list?

I can enumerate use cases where the lack of availability of grouped 
elements in completion-at-point-functions was a real problem (basically, 
yasnippet, which isn't really completion, and file path completion, 
which has peculiarities that should ideally be tweaked on a 
per-language-and-project basis; both of these would be nice to have, 
though). I'm sure there will be corresponding cases with xref, but we 
haven't touched on those.

On 05/09/2015 12:52 AM, Vitalie Spinu wrote:

> I am afraid this is an impossible task.

I think we can get close enough. At least as far as most users are 
concerned; and offer additional customization for the rest.

> These tools live and work in different contexts. They are overlapping in
> purpose but each does an unique job in situations in which other 2 are
> not even defined. There is only one way to merge them into one "super
> tool" - write one that does each of them in in their own application
> context.

That description fits the "first one wins" approach as well. Even more 
so since you wrote "different contexts". An argument against would be 
stating that there are contexts where we really can't pick which tool to 
use. Contexts in which they all return equally useful, but different, 
results together.

> Anyways, I am summarizing my point in a final attempt to "make a case";)
>
>    - 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.

The quality of Imenu indexing is usually pretty low (lots of duplicates 
due to methods with the same name), so I'd put it on the last position: 
use only when we can't find a better alternative.

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

Multi-language projects are an interesting example. But if there are no 
references between the source file in different languages (or if there 
are, how would you handle them?), this case devolves into the situation 
of having several projects, semantically related.

Personally, I'd just make a "switch to another project" a separate step 
here.

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

It's not ideal, no argument here. However, being unavailable in buffers 
without TAGS, or in some languages, means it can be safely skipped in 
those circumstances. No need to merge.

> The above is also the order that I would like to have in my backend
> list.

I'm pretty sure Imenu can't be the default backend to use. And you were 
proposing to show only the results from the first backend in the list, 
right? Until the user asks for the rest?