bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags


From: Dmitry Gutov
Subject: bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags
Date: Sat, 12 Mar 2016 03:08:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

On 03/11/2016 04:59 PM, Eli Zaretskii wrote:

I said "etags", not "emacs".

I don't think this implies any considerable amount of work in etags either. I could be wrong, of course.

And allowing the output of qualified+unqualified, in etags, doesn't seem
like a huge job to me.

For languages where qualified tags are already created, maybe.

And it is those languages where I think the users would be served better by a different behavior.

(C-like languages might be not so easy, due to the state machines they
use.)  But are we sure all languages do?

I'm sorry, all languages do what? Use state machines, and thus are "not so easy"?

We can perfectly well choose to support this feature only for a few
languages. It's better than nothing.

I'm not sure "better than nothing" is good enough.

I'm not buying the argument that doing the right thing is somehow undesirable because we can't afford to do the perfect thing right now.

Especially since the transition path from "good" to "perfect" is natural in this case (just add support for more languages later). This way, you won't have to change the semantics of -Q in future releases, or invent another flag that behaves similarly to -Q, "but better", and deal with having to document that -Q is not actually recommended for use.

Anyway, I don't really understand what we are arguing about.

I'm arguing that -Q should output both qualified and unqualified tags, so that the result is actually useful.

You seem to be arguing towards -Q preserving the previous behavior of the parser, _in certain languages_, no matter the usefulness of the resulting tag files.

Apparently, to support some consumers of tag files that do it in a fashion we can't predict, and might somehow be inconvenienced if the "qualified-only" output is not one of the options. Is that correct?

Here's the relevant excerpt from ctags's manpage:

Thanks, but why do you think I don't have it installed?

You might, or you might not. It was easier to quote directly.

Does that excerpt not make sense to you?

Ultimately, it's your choice, of course.

Volunteers are free to beat me to it, if they have an itch to scratch.

If you've made a deliberate choice, it doesn't seem like a patch from a volunteer that would make a different choice is likely to be accepted.





reply via email to

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