Re: xref-find-matches and stuff

[Vitalie Spinu]

 >>> Dmitry Gutov on Wed, 6 May 2015 03:48:14 +0300 wrote:

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

 > Feel free to make the case with specific examples; maybe implement a
 > usable elisp+etags configuration.

I have the following patterns in mind:

  1) etags + mode-specific-backend 
  2) imenu-anywhere + mode-specific-backend
  3) etags + imenu-anywhere + mode-specific-backend

Imenu-anywhere [1] allows you to jump to imenu references in all files
with the same mode. It can get more refined as imenu-in-same-project
which could use some notion of a project.

I think everyone would like to have 2 or 3 by default because it makes
references available even if there is no repl running or tag tables
loaded. Imenu is also always uptodate, so should get higher priority.

Semantic references could also be used instead of imenu. I personally
don't use them.

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

That's major mode developers have to answer as they see fit. If you have
a clear semantics of how merged backends behave your job with xref is
done.

If you have a good UI that allows quick manipulation of backends, major
modes might want to define multiple backends to fit more user patterns.

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

That's the problem to be solved. And someone has to solve it anyways.

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

You might be right. The only complication is that xref-backend is set by
major mode so I will have to overwrite it by xref-multi everywhere.

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

I am not sure I understand. The only xref-loc that doesn't have explicit
:file slot is xref-buffer-location but you can easily extract the file
or simply use the buffer name for non-visiting files.

 > So far it looks right:

Ok. Let's see how it goes. My gut feeling is that it might get too
complex and very few backends will actually extend it.

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

Isn't this class a complication? Cannot you just have optional
:description slot in root xref-location class? Some backends will be
able to return directly the :description field.

By merging xref--xref and xref-location you will reduce the clutter and
simply call "xref" what you call "xref-location" right now. You get
"xref" instead of "xref-location" - "elisp-xref", "etag-xref"
etc. Cannot get simpler!

Displaying xref--xref instead of the xref-location is rather awkward
design from the backend developer prospective.  For each of the location
class you will need to define a pairing `xref--xref` class:

 (defclass my-xref-location ...)
 (defclass my-xref-xref ...)


BTW, :description is not very suggestive to me. How about :locstring to
emphasize that it's a string representation of the location?


  Vitalie



[1] https://github.com/vspinu/imenu-anywhere