Re: xref-find-matches and stuff

[Dmitry Gutov]

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

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

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?