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: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
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 17:28:01 +0300

> Cc: 20629 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 27 May 2015 02:56:02 +0300
> 
>     I don't see how that could be possible: tag-implicit-name-match-p is
>     language-agnostic.  You'd need to make it language-aware before it
>     could do such stuff for languages that need it.
> 
> Well, by including ()=,; in that constant, it already makes certain assumptions that aren't necessarily true (for instance, `=' can be, and often is, a part of a method name in Ruby). Adding a colon would be another one of those.

That's not the same situation: [()=,;] are used only if there's no
explicit tag name; explicit tag names are used without any processing,
and the language-specific parsing in etags.c is expected to extract
the tag name according to the language-specific rules.  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.

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

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.

> You should try the patch and see how it goes.

I will, thanks.

Previous Next

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