[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: Wed, 6 May 2015 03:48:14 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

On 05/05/2015 08:17 PM, Vitalie Spinu wrote:

I don't quite understand your opposition. Multiple backends is such a
common requirement that you will need to set 'xref-multi by

I guess I don't see it that way. We currently don't have multiple values in any major mode. The third-party project I intend to use xref in, won't have them too. Feel free to make the case with specific examples; maybe implement a usable elisp+etags configuration.

Without multiple values in the core, I can avoid asking questions like:

- If I'm a major mode, what do I do with xref-backends? Do I set it to a single-value list? Do I prepend to it?

Out usual strategy is to use a hook (like a list of functions), but in those kind of setups, we usually run the hooks until one of the elements returns something interesting, rather than combining all results.

- If I'm a minor mode, what do I do with it?

- How are xref-identifier-completion-table-function values combined? completion-table-merge, or completion-table-in-turn? What are performance characteristics of calling completion-table-merge on five tables? Are you aware that a completion table produced by either of these functions can't handle certain advanced metadata that might be present in some of the original completion tables?

Having a parallel xref-multi engine would necessary involve
replication of variable names and, hence, needless burden on the users
and developers. What's the point?

What variables? I can only see one: xref-multi-backends. Then you set xref-backend to `xref-multi' in the minor mode function and implement the four or so methods on it, delegating each to the current list in xref-multi-backends, and combining the results somehow (nconc, for most of them).

Anyways, I expect it to be no more than 100 lines of code. So I can
implement it both ways and we can see which one is better afterwards.

Since the simplest implementation can be very simple, it can also be an argument not to have it in the core. Backend author can make the choice, if it comes with this low a cost.

Of course. This one is a particularly interesting example. Both etags
and elisp return name and file, but elisp doesn't return a line. So in
order to make them compatible you must avoid using lines in the uniform
identifier. So it could be in file:symbol:type format, or
editfnc.c:system-name:defun in your example.

Yup. Or rather /path/to/editfns.c:system-name:defun (etags has the full path, elisp doesn't; we should expand it).

I think this is a general enough convention that will probably work
reasonably well in most of the cases. You can also have several levels
of "uniqueness" of the uniform identifier, xref-uname-lax, xref-uname
and xref-uname-strict. The lax one can be file:symbol; the strict one
can be file:symbol:type:line:column.

The last one is redundant: if we have file, line and column, we don't need the symbol and its type.

However, note that both representations you've chosen require a file name. Currently, an xref could only include some info that it needs to find out the file name (lazily), and it can return something else as its "group". We can only enable duplicate-remove-ability for certain types of xrefs, though.

In *xref* buffer you might have a command that will rotate through
levels of "uniqueness".

FWIW, that's too many user choices for my liking.

I meant that if you already got into *xref* buffer with many
alternatives there should be commands to refine duplicates on different
criteria, just as I have described above.

See above. Don't ask the user to do what a machine could. If unwanted duplicates happen, we should write smarter backends.

The problem still remains when you have small number of matches that
give the same location. You don't want to popup *xref* in that case. But
I think the above uniform identifier idea will reduce this problem to

I think duplicates removal is kind of important, especially for xref-find-definitions. It's the difference between having to choose and being taken to the right option immediately.

This looks like an over-engineering to me. Why to allow locations to
display differently? To bother users with different colors and
arrangements? Do you have examples when different location classes need
to display differently and simple non-generic display would not work?

It's an implementation technique. The fact that a backend implementor will be able to insert a nyancat animation after every line doesn't mean they will; everyone can mess will any Elisp function anyway, and don't get me started on custom faces that don't fit the default theme, or any light-background one. Anyway, the fact that some people could too easily change a piece of Emacs behavior to their liking shouldn't be an argument against this.

So far it looks right:

- You want shortened file paths, a "file path" group class would fit.

- Helmut suggested that xref-find-apropos output for Elisp looks closer to M-x apropos. We could do that with special elements. Likewise, apropos output for a different language would look different and use different properties, which we cannot anticipate. Flexibility here should be beneficial.

- Elements can have different roles; for instance, a group could also be an xref. Like, for instance, xref-find-references can match something in a function declaration (name or argument), and some references inside it. The output could have the method displayed as a match, as well as group the matches inside it.

- In certain cases, a file name might be a match for a search, so it could be fitted into the hierarchy. In an environment where classes and file names are usually tied (like Java or Ruby), a rename operation, ideally, should handle both.

If, on the other hand, a fixes set of structures is all we need for the data returned by the backends, the backend authors might limit themselves to the built-in ones, and avoid spending effort on extensions.

Anyways, I want my locations to display the same and have same UI for
all backends, so I am sticking to my tabular display.

If people add new structures, we should recommend to inherit from the built-in ones. So you'd still render them automatically, even if missing some extra fields.

> Would be nice if
your new generic system would allow me to easily overwrite the default
display methods for all xref-locations at once. I don't want to hunt
them one by one afterwards.

The location classes are unlikely to change much. We're displaying xref--xref instances, though, and that hierarchy will see some growth. Any suggestions for a better name, by the way? xref-item?

reply via email to

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