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

Previous Next

Full log

Message #236 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: Sat, 30 May 2015 22:42:26 +0300

On 05/30/2015 09:46 PM, Eli Zaretskii wrote:

> You said "based on correctness".  If the 2-entry alternative
> facilitates more correct operation, that's the alternative we should
> choose, no?

It adds a capability (to perform the search based on fully qualified 
name), rather than improving correctness.

But again, it's a separate question. You don't have to persuade me on 
that choice, but I'm inclined toward compatibility with Ex-Ctags.

>>> Then how will you find or complete on "foo" when the explicit tag is
>>> "XX::foo"?
>>
>> I'd like to repeat that the current choice is between having only
>> unqualified method names in explicit tags, or having both qualified and
>> unqualified method names (2 entries per line).
>>
>> Having only a qualified entry is not a situation we're going to handle.
>
> You elide too much of the previous context, and I cannot afford
> reading 2 or 3 previous messages to restore that (and please don't
> rely on my memory too much).  So I no longer understand what we are
> talking about here.

Sorry, I don't know where to start clarifying. In the previous message 
I've explained why your question, quoted above, doesn't make sense: the 
TAGS file must have another entry, for the same line, where the explicit 
tag is "foo". That one will be matched, not "XX::foo".

This discussion has grown quite long already. Francesco seems to agree 
with my conclusions, so I'm going to make the change.

> Including the pattern (what you call "the implicit tag") in the
> completion table could serve as context for disambiguating otherwise
> similar tag names.  But if you think it's unneeded, I'm not going to
> argue.

Here you're using a term that's not part of the usual completion table 
terminology. Context? Apparently you mean annotation, which would be 
possible (*), but using the pattern as annotation for the current 
entry's tag name is not at all the same as including the implicit tag 
name (derived from the pattern) in the completion table. Which means 
adding it as a separate element. For simplicity, think of this 
completion table as a list, especially now it's implemented as such.

(*) But not necessarily advisable, and would bring its own challenge WRT 
implementation.

Previous Next

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