Re: xref-find-matches and stuff

[Vitalie Spinu <spinuvit@gmail.com>]

 >>> Dmitry Gutov on Tue, 5 May 2015 18:23:54 +0300 wrote:

 > Nope:

 >      (setq xref-backend 'elisp)

 >> for current backends. Then adding functionality to add/remove backends
 >> from current list and rotate through different preset configurations of
 >> backends is a piece of cake.

 > You would do (setq xref-backend 'xref-multi) in your minor mode, and write
 > implementations delegating to the list that your mode stores
 > internally.

I don't quite understand your opposition. Multiple backends is such a
common requirement that you will need to set 'xref-multi by
default. 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?

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.

 >> You can define `xref-loc-name` methods for location objects to
 >> extract a wanna-be-unique name to be specifically used in comparison
 >> between backends.

 > That's an interesting proposition. Will it help with duplication between

 > (defun system-name)

 > from elisp and

 > DEFUN ("system-name", Fsystem_name,

 > from etags?

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.

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.

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

 >> Even if you cannot get rid of all duplicates it's the task of
 >> the *xref* UI to provide sorting and duplication removal on specific
 >> attributes.

 > I don't really understand this, but I probably disagree. :)

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.

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.

 >> If you are willing to wait till 20th of May I can propose patches for
 >> this abstraction change and other UI ideas that we have discussed
 >> elsewhere.

 > Changing backends to use generics is fairly orthogonal to what I have
 > planned next, so please do that at your convenience.

Ok.

 > As for the UI, if you don't simply mean the said mode, but also the
 > alternative xref output, I'd rather you wait with that for a
 > while. The generics-based rendering and the grouping widgets will
 > bring a lot of changes.

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?

Anyways, I want my locations to display the same and have same UI for
all backends, so I am sticking to my tabular display. 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.

Thanks,

 Vitalie