[Top][All Lists]

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

Re: xref-find-matches and stuff

From: Dmitry Gutov
Subject: Re: xref-find-matches and stuff
Date: Sat, 9 May 2015 03:09:00 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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

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

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?

reply via email to

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