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: Eli Zaretskii
Subject: bug#22947: 25.0.92; xref-find-definitions fails for Perl & etags
Date: Sat, 12 Mar 2016 09:41:42 +0200

> Cc: 22947@debbugs.gnu.org, rogers@modulargenetics.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 12 Mar 2016 03:08:13 +0200
> 
> 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.

I just said that etags never had these features, so we are talking
about an enhancement, not a bugfix.

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

I'm not selling it.

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

No, I'm just saying this is a new feature whose implementation costs
are unknown to me at this point.

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

I've made no choices, except not to work on this today.  I don't
understand why you think I'm against adding such a feature, if done
cleanly.  It's almost a reason to take offense, since I never said
anything that could be interpreted as such an intent.





reply via email to

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