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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20629 <at> debbugs.gnu.org
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

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.