Re: xref-find-matches and stuff

[Vitalie Spinu]

 >>> Dmitry Gutov on Thu, 7 May 2015 03:09:37 +0300 wrote:

 >> 1) etags + mode-specific-backend

 > Why not use etags

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

 > As long as tags are not available, why not simply leave it to the
 > major mode?
 
 >> 3) etags + imenu-anywhere + mode-specific-backend

 > Use tags. :)

There are many situations when you cannot or might not want to use tags:

   - In many common situations tags don't apply. For example open a file
     with an example, or create a temporary scratch file to experiment
     with features.

   - There are plenty of languages that don't have tags support and
     nobody would care to add it.

   - A lot of less techy people would not use etags because it's a
     command line tool which is usually called with arguments. You said
     you are not using tags routinely. I do, and it's frustrating to run
     to terminal and visit tag table each time you need to jump to a
     reference in a new context.

   - Current emacs tags UI is clumsy and not project oriented. I am now
     always annoyed when elisp-xref takes me to emacs C source and from
     there etags brings me to my R projects.

   - When working with multiple projects, tags generation is
     frustrating. It assumes that you know all the projects and all
     non-project files you will be dealing with. That's commonly not
     true.

You would like to use imenu because:

   - Imenu is meaningful in non-programing modes and for non-visiting
     buffers.

   - Virtually all modes already define imenu, so it works out of the
     box everywhere, even if you read a language in which you will never
     write.

   - And finally, imenu operates on what you work on - open files - you
     don't get thousands of symbols from etags to deal with.

I have been using imenu-anywhere for a couple of years now and it has
been a much better, more uniform and more consistent experience than
anything else I have tried.

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

Yes. That can be. But I am setting xref-prompt-for-identifier /and
recommend it widely ;)/. That implies a merge.

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

Sure, I will give it a try in a couple of weeks.

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

Ok, I see. But uniform identifier (xref-uname) method should then be a
requirement.

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

And that's not a bad thing. You would like to have as much uniformity as
you can.

I wonder if the whole interface could be made a bit stricter. It always
makes sense to have a string representation of the container (file-name,
buffer-name, document name), right? So maybe get the common root slot
:container or :context?

Also :line and :column slots always make sense even if they are not
populated from the start. For example xref-buffer-location can still
have :line and :column optional slots because some backends (like imenu)
could already have those precomputed.

 > Or a more practical side, maybe xref-description can become a generic
 > method. 

Could be. Then the backend can decide whether to store it as part of the
object or not.

On the other hand you would want to be able to regexp through the
descriptions without sniffing through all the files? So it might be
reasonable to "kindly suggest" pre-computing that information by adding
an optional :description slot.

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

This doesn't fit nicely with my tabular-display intention, nor, I think,
with your custom displays idea. I would prefer a description method.

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

Exactly!

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

What's the problem? I can still define a root class `xref` and use
`xref` to mean "an object that stores a location metadata".

Alternatively `xref-root` for the root class and `XXX-xref` for
everything else. 

 > but otherwise, merge it is.

Great!

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

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

My problem with "description" is that it's too general. Description can
mean anything - documentation of the symbol, description of the xref
object, description of the context at point, or, as it's currently used,
a declaration of the object from the original location.

Summary is better but it's also open to interpretation. How about saying
what it is - "declaration" ? Or even better "content" to emphasize that
it's a content at that physical location? Then print methods can
manipulate this string in whatever way they see fit.

  Vitalie