[Top][All Lists]

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

bug#20629: 25.0.50; Regression: TAGS broken, can't find anything in C++

From: Francesco Potortì
Subject: bug#20629: 25.0.50; Regression: TAGS broken, can't find anything in C++ files.
Date: Thu, 28 May 2015 17:29:39 +0200

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

reply via email to

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