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

[Dmitry Gutov]

On 05/27/2015 05:28 PM, Eli Zaretskii wrote:

> That's not the same situation: [()=,;] are used only if there's no
> explicit tag name;

tag-implicit-name-match-p is used either way.

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

That was my understanding as well. However, whether explicit tag names 
are included or not, doesn't have a lot of effect on my alternative 
suggestion.

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

No, to process patterns. I don't think we've ever had qualified explicit 
tag names, did we?

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

Running 'etags -Q', and updating tag-implicit-name-match-p to also 
include : in NONAM should both show us the qualified names in the 
completion table, as well match the unqualified names when asked for tags.

> > You should try the patch and see how it goes.
>
> I will, thanks.

Let us continue this discussion when there's some feedback on it.