Re: xref-find-matches and stuff

[Dmitry Gutov <dgutov@yandex.ru>]

On 05/06/2015 04:54 PM, Vitalie Spinu wrote:

> I have the following patterns in mind:

Allow me to offer some sloppy critique.

>    1) etags + mode-specific-backend

Why not use etags, rather than rely on the major mode and it being able 
to only each the buffers currently open in Emacs?

If the problem is that etags is imperfect, let's refine its regexps. If 
its getting out of date is the problem, we could automate something in 
that area too, or switch to something more advanced. E.g. 
https://github.com/leoliu/ggtags boasts automatic updates as the number 
2 in its features list.

>    2) imenu-anywhere + mode-specific-backend

As long as tags are not available, why not simply leave it to the major 
mode? It's sure to be able to provide a more precise data than an 
adapter on top of Imenu.

There's not even a clear standard on the Imenu index structure: e.g. 
flat vs. nested.

>    3) etags + imenu-anywhere + mode-specific-backend

Use tags. :)

I think this list is a reasonable case for a hook of the usual kind 
though: whichever backend returns non-nil to 
`identifier-completion-table', gets used.

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

CEDET could be rough around the edges, but it'll beat Imenu and etags. 
Its parsing engine, the symbol database and integration with external 
tools map to all backend features we might have planned.

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

Like I said, I'd prefer to hold off on dealing with this yet. But don't 
let me stop you.

We could as well introduce merged backends as a core feature later, by 
setting xref-backend to a list, or use a combinator function. Although 
the latter might be tricky with a generics-based backends.

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

That's what minor modes often do.

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

I mean that including a file name is not mandated by the xref interface. 
Backends are allowed to provide their own xref-location implementations, 
and some of those might be missing the file slot as well.

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

We'll see. And few backends extending it sounds about ideal to me. We 
don't want the user experience to vastly differ between backends either.

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

It might be. But so far, xref-location is effectively just an interface. 
Adding a slot will take us closer to inheritance.

Or a more practical side, maybe xref-description can become a generic 
method. If can certainly be deduced from the contents of 
xref-elisp-location, as well as xref-etags-location and 
xref-buffer-location. xref-file-location would need to store it in a slot.

Or, along the lines of the OO proposal, it could be entirely replaced 
with an xref-buffer-print generic method. You don't ask a location its 
summary, just ask the object to print itself.

That may be suboptimal from the standpoint of an alternative interface, 
though.

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

That is indeed simpler, but the package is called xref already, maybe we 
should use some suffix in the name of the location base class.

Thanks for the merge suggestion either way.

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

I suppose, if the "render me" method is defined on xref-xref, rather 
than on xref-location. But if not, xref-xref doesn't serve a lot of 
purpose indeed, right now it's simply a two-slot container without any 
associated generic methods.

Keeping it separate would be useful if we find two orthogonal 
hierarchies peeking though the planned functionality, but otherwise, 
merge it is.

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

Replace one common word with a portmanteau?

It's not really a representation, just something to show in the buffer. 
Call it summary maybe? Both descriptions and summaries are usually strings.