GNU bug report logs - #20629
25.0.50; Regression: TAGS broken, can't find anything in C++ files.

Previous Next

Package: emacs;

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

From: Francesco Potortì <pot <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 20629 <at> debbugs.gnu.org
Subject: bug#20629: 25.0.50; Regression: TAGS broken, can't find anything in C++ files.
Date: Thu, 28 May 2015 14:16:21 +0200
>> In class-based programs,
>> like C++, it can be useful to provide a fully-qualified name for an
>> identifier, so there is a class::id tag.  Here again, it may make sense
>> to tag all entries, if it makes TAGS parsing easier or more accurate.
>
>The question at hand is how Emacs should go from a non-qualified tag 
>name (because it's a method call in the buffer, and we don't know which 
>class the object belongs to) to the tag location. Either we use some 
>implicit matching, or each method tag should have two entries: a 
>qualified one, and a non-qualified one.

Well, I'd say, when matching NAME:

first, match against a tag NAME
second, if appropriate, match against a tag ::NAME
third, regex match against a tag .*::NAME$
fourth, match against the entry, without looking at the tag

I would have said that it is already implemented like this, but in fact
I cared about etags.c, not much about etags.el.

As I said previously, whether the tag is implicit or explicit makes no
*logical* difference, but it can impact performance.




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.