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

[Eli Zaretskii]

> Cc: 20629@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 27 May 2015 02:56:02 +0300
> 
>     I don't see how that could be possible: tag-implicit-name-match-p is
>     language-agnostic.  You'd need to make it language-aware before it
>     could do such stuff for languages that need it.
> 
> Well, by including ()=,; in that constant, it already makes certain 
> assumptions that aren't necessarily true (for instance, `=' can be, and often 
> is, a part of a method name in Ruby). Adding a colon would be another one of 
> those.

That's not the same situation: [()=,;] are used only if there's no
explicit tag name; explicit tag names are used without any processing,
and the language-specific parsing in etags.c is expected to extract
the tag name according to the language-specific rules.  The idea
behind tag-implicit-name-match-p is an observation that in many
practical cases [()=,;] delimit the tag name, and when it does,
etags.c could refrain from putting an explicit tag name in TAGS.  IOW,
this is just an optimization, meant to keep TAGS smaller.

By contrast, what you are suggesting (AFAIU) is process an explicit
tag name, such as "foo::bar::baz", to deduce that it matches "baz".

Or maybe I don't understand the suggestion, since you were talking
about tag-implicit-name-match-p, which doesn't look at the explicit
tag name at all, and the explicit tag name is the root cause here.

> You should try the patch and see how it goes.

I will, thanks.