[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
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.
- Re: xref-find-matches and stuff, (continued)
Re: xref-find-matches and stuff, Vitalie Spinu, 2015/05/05
- Re: xref-find-matches and stuff, Dmitry Gutov, 2015/05/05
- Re: xref-find-matches and stuff, Vitalie Spinu, 2015/05/05
- Re: xref-find-matches and stuff, Dmitry Gutov, 2015/05/05
- Re: xref-find-matches and stuff, Vitalie Spinu, 2015/05/06
- Re: xref-find-matches and stuff, Dmitry Gutov, 2015/05/06
- Re: xref-find-matches and stuff, Vitalie Spinu, 2015/05/07
- Re: xref-find-matches and stuff,
Dmitry Gutov <=
- Re: xref-find-matches and stuff, Francesco Potortì, 2015/05/08
- Re: xref-find-matches and stuff, Dmitry Gutov, 2015/05/08
- Re: xref-find-matches and stuff, martin rudalics, 2015/05/10
- Re: xref-find-matches and stuff, Eli Zaretskii, 2015/05/10
- Re: xref-find-matches and stuff, martin rudalics, 2015/05/11
- Re: xref-find-matches and stuff, Eli Zaretskii, 2015/05/11
- Re: xref-find-matches and stuff, martin rudalics, 2015/05/12
- Re: xref-find-matches and stuff, Eli Zaretskii, 2015/05/12
- Re: xref-find-matches and stuff, Dmitry Gutov, 2015/05/12
- Re: xref-find-matches and stuff, Eli Zaretskii, 2015/05/12