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

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.

reply via email to

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