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

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

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

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,


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.

reply via email to

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