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

["Francesco Potortì" <pot@gnu.org>]

Dmitry Gutov:
> It's harder to present a realistic case of a user looking for one thing 
> and getting another, but the point is, is the Etags parser decided that 
> the implicit tag doesn't match the explicit tag, we should ignore the 
> former (because we don't really know the way they mismatch).

...

>Currently, we don't put the implicit tag into the completion table if 
>the explicit tag is present.
>
>But we do match implicit tags during navigation, even when an explicit 
>tag is there.
>
>The aforementioned patch would include the implicit tag in the 
>completion table anyway. I'm now saying we don't want that, and we also 
>don't want navigation to match implicit tags in the entries that contain 
>an explicit tag as well.

Sorry if I don't closely follow the discussion (I do not know all the
internals of etags.el), and consequently sorry if I am misanderstanding
anything.  In that case, please discard my observations below.

I fear I can read in the above quotes a fundamental misunderstanding.
If Emacs (etags.el or anything else) treats implicit tags differently
from explicit tags, that's an error.

Implicit tags are semantically the same as explicit tags.  Whether a tag
is implicit or explicit, it's only a matter of efficiency in building
the TAGS file. For a given TAGS file entry, there is either no tag, or
an implicit tag, or an explicit tag.  The latter two cases should be
treated exactly alike by whichever program is reading the TAGS file.
Nor is it possible that for a given entry its implicit tag does not
match its explicit tag, because either the former or the latter are
present, not both.