GNU bug report logs -
#20629
25.0.50; Regression: TAGS broken, can't find anything in C++ files.
Previous Next
Reported by: "Jan D." <jan.h.d <at> swipnet.se>
Date: Fri, 22 May 2015 05:59:02 UTC
Severity: normal
Found in version 25.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> Date: Sat, 23 May 2015 17:46:18 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 20629 <at> debbugs.gnu.org
>
> > Date: Sat, 23 May 2015 16:50:11 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Cc: 20629 <at> debbugs.gnu.org
> >
> > We should try to fix bugs without re-introducing previously solved
> > ones.
>
> Does the patch below give good results in real-life C++ usage?
>
> Please also consider whether this change could cause trouble in other
> C++ use cases. (I've ran the modified version on the etags test
> suite, and didn't spot any problems in the differences with the
> previous results, but I don't consider myself an expert on C++
> syntax.)
I see that etags deliberately produces explicitly named tags of the
form CLASS::MEMBER, whenever it sees a declaration of MEMBER inside a
class declaration of CLASS. Why is that useful? It is another
instance that defeats the change which removed tag-symbol-match-p from
the "order" functions used by etags.el when invoked from xref. Does
anyone see a problem with removing this feature from etags?
This bug report was last modified 9 years and 69 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.