[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: Dmitry Gutov
Subject: bug#20629: 25.0.50; Regression: TAGS broken, can't find anything in C++ files.
Date: Wed, 27 May 2015 18:28:10 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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.

reply via email to

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