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

Previous Next

Full log

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

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

On 05/29/2015 11:12 AM, Eli Zaretskii wrote:

>>> But having just qualified tags is bad for accuracy, right?
>>
>> Maybe. Depends on things we would add to the Lisp code.
>
> Can you elaborate?  Is there a way to get the same accuracy and
> completion without having both qualified and unqualified tags?

There'll have to be some compromise, but not necessarily in accuracy. 
The present default behavior is accurate enough, and by that I mean the 
user can navigate to a method call, press M-., and see all definitions 
of the methods with that name, without extra junk.

What we don't have by default, is completion, and navigation to, 
qualified method names. That's by itself, is a relatively advances 
feature (the user needs to know to press C-u and then either press TAB 
and look for qualified names, or type one out).

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). So, 
having qualified names in tag completion reliably is out of the 
question, unless etags uses them in tag names.

And then we'd have to solve the question of how to get the unqualified 
names in both completion and navigation (continued below (*)).

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

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

(*) However, I don't really understand this choice:

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

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.

Previous Next

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