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

[Francesco Potortì]

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