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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 20629@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 29 May 2015 17:05:53 +0300
> 
> That can be mitigated by parsing out implicit tag names out of patterns, 
> however they also don't always contain qualified names (which was my 
> misunderstanding: they do in the toy example provided by Jan).

At least in C++, class members can be qualified explicitly in the
source (which was what Jan's example did), or they can be qualified
implicitly, by including them inside braced constructs, for example.
For the latter, etags (now only under -Q) adds the qualifications when
it generates the tags.

The code I added _removes_ the explicit qualifications, and doesn't
add the ones for implicitly qualified members.

> So, having qualified names in tag completion reliably is out of the
> question, unless etags uses them in tag names.

Exactly.

> > Yes, but I think if we change etags to create duplicate tags, we
> > should have this feature opt-out, unlike Exuberant, otherwise TAGS
> > created by default will be deficient with xref.  Do you agree?
> 
> I'd say no. First, there's value is simply being compatible.

Compatibility aside, I think what most users will want should be the
default.  What Exuberant ctags does now might not yet reflect the
changes in Emacs, from etags.el's UI to xfer.  Once they learn about
that, they might turn that flag on by default as well.

> Second, as the ctags man page warns, including both qualified and 
> unqualified names in separate entries, "could potentially more than 
> double the size of the tag file".

Who cares?  Disk space is no longer at premium.

> Which increases the time it takes to load one, and might (if we make
> more progress on Stefan's suggestion not to pre-build tags
> completion table) also make completion slower, in projects of
> certain size.

For moderate-size projects, the obarray-based completion is
instantaneous, so I'm not afraid of this.

> """
> The actual form of the qualified tag depends upon the language from 
> which the tag was derived (using a form that is most natural for how 
> qualified calls are specified in the language). For C++, it is in the 
> form "class::member"; for Eiffel and Java, it is in the form "class.member".
> """
> 
> If we posit that in each interesting language a qualified tag is of the 
> form CONTEXT-CHAR-NAME, standardizing on CHAR would allow us to extract 
> both qualified and unqualified tag names from a single entry, at a small 
> cost in readability for users where the language traditionally uses a 
> different separator than the one picked by etags.

I don't think we can safely do that, since different characters can
appear in identifiers of different languages.  By using the qualifier
string that is natural for the language, we make sure we never get
conflicts with the identifiers themselves.

Also, these qualified tags are for human consumption, which is another
argument on favor of language-specific syntax.

> For better uniqueness, I'd choose two of them: # before instance 
> methods, and . before class (or static) methods. This notation is fairly 
> popular and is used in Javadocs, as well as in different comment formats 
> Ruby uses.

Which means C++ programmers will probably be confused by them.