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

Previous Next

Full log

Message #77 received at 20629 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 20629 <at> debbugs.gnu.org
Subject: Re: bug#20629: 25.0.50;
 Regression: TAGS broken, can't find anything in C++ files.
Date: Wed, 27 May 2015 18:46:54 +0300

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

Maybe I'm confused, but what about tag-exact-match-p?

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

Yes, we did.  That's what the -Q switch controls.

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

I guess I really don't understand your suggestion, then.

Previous Next

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