Re: xref-find-matches and stuff

[Dmitry Gutov <dgutov@yandex.ru>]

On 05/07/2015 03:24 PM, Vitalie Spinu wrote:

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

None of them, AFAICS, provide justification to use the "merge" strategy 
for backends, rather than "first one wins". And the latter is easier to 
implement.

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

If xref-backends is a list with a value like '(etags elisp imenu), first 
we'll try etags. If it's not applicable (no tags file), then the major 
mode, if there's an entry for it. Otherwise, imenu (that element has 
probably been added by a minor mode).

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

For people with aversion to contributing patches upstream, ctags also 
supports specifying necessary regexps on the command line: 
https://gist.github.com/wereHamster/1299204

That should work at least as well as most uses of Imenu.

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

Then don't use ctags. Use GNU Global, or something else. I see you've 
skipped me mentioning ggtags in the previous message.

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

Recalling previous discussions on the subject, that's pretty hilarious. 
Sorry. Like Stefan suggested before, maybe etags should look for the 
tags file automatically in the parent directories of the current file. 
Not everyone would like that, but it seems like it would be a better 
default.

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

This is a big vague, so I'm not sure exactly what to propose. But it can 
probably be improved as well.

To sum up, my point is that if there are obvious deficiencies in the 
tools we have, it's better to improve or replace some of them, rather 
than try to simply cobble them together and let the user sort out the 
overlaps.

> You would like to use imenu because:

None of these examples seem to be calling for merging with results 
returned by etags either.

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

That's good. But that may speak more about the availability and ease of 
use of other tools, rather than about imenu-anywhere itself.

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

I don't understand. How does it imply that?

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

We can try to make it that, but it's not easy to come up with a good 
specification.

And what about etags? If we want to remove duplicates when merging etags 
with any third party language backend, it seems like etags should return 
close-to-ideal unames for tags in any language. Certainly without 
duplicates.

I can imagine us swinging it for Emacs Lisp (language with no classes in 
the modern-OO sense, no namespaces), but Ruby, Java, JavaScript?

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

Actually, we'll probably remove xref-location altogether (it currently 
has no specialized method implementations now). Without this mandated 
paren class, locations can be structs as well as classes (cl-defmethod 
supports both), and we don't need to worry about classes being able to 
inherit from structs or vice versa.

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

There might be no container. There'll likely be several containers 
nested inside one another, at least in certain outputs.

It seems to call for a separate types of values (different containers). 
You'll still be able to flatten that tree during output.

I'm not sure yet whether an element should have a reference to its 
parent container.

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

But why? You can ask an xref-buffer-location for its line and column, 
and it'll tell you. No need to create slots for them.

> 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 we find C-s insufficient, we could ask all of them for descriptions 
again. So far, the vast majority of time xref-find-references spends in 
is opening files. Everything else seems to be an order of magnitude faster.

If not, the interface could also cache descriptions separately.

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

Okay. Always having some sort of line identifying a reference makes 
sense anyway.

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

No problem, just fairly awkward, in my view. Also, M-. will always ask 
you which one you mean.

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

True.

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

I agree summary is not ideal.

"Declaration" doesn't work in all situations we'll use it in: 
declaration of a grep match? Declaration of that place this function has 
been used in?

"Content" is better, but the elisp backend doesn't return buffer 
contents (for the obvious reason: it's not opening any files until 
asked). I can see other backends doing the same. Still, it's probably 
the best of the current options.

"Display" would be closer, I think, but it's Emacs slang, and not 
something any reader will understand.