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
Message #125 received at 20629 <at> debbugs.gnu.org (full text, mbox):
>Eli Zaretskii:
>>> Francesco Potortì wrote:
>>> >> second, if appropriate, match against a tag ::NAME
>>> >> third, regex match against a tag .*::NAME$
>>> >
>>> >Why can we use colons? That implies some sort of knowledge about C++,
>>> >whereas until now etags.el has remained language-agnostic.
>>>
>>> Mh. I had taken it for given that each major-mode in fact added
>>> something to the list of functions called when looking for a tag.
>>> Doesn't it work that way?
>>
>>No.
>>
>>In addition, doing so would not work if I tried to look up a symbol in
>>language A from a buffer whose major mode is tailored to language B.
>>
>>> If not, couldn't it be done for languages where the
>>> language-agnostic behaviour of etags.el is not satisfactory?
>>
>>etags.el relies on etags.c to know languages well enough to do that
>>part of the job. I think we should keep this separation of
>>responsibilities.
>
>I see. Given these constraints, I see no other way than augmenting the
>TAGS format to include an arbitrary number of tags per entry...
Answering to myself: yes, Dmitry's suggestion would not even need
changing the TAGS format. For class-based languages, in addition to the
currently generated entry which contains a fully-qualified tag, generate
an additional entry containing an unqualified tag (which most of the
time will be an implicit tag).
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.