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

Previous Next

Full log

Message #215 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: Sat, 30 May 2015 19:37:48 +0300

> Cc: 20629 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sat, 30 May 2015 18:03:18 +0300
> 
> >> - Like you mentioned, it's not always that qualified name occurs in the
> >> pattern. Sometimes it's creates using curly braces and such, and thus
> >> can only occur in an explicit tag name (which the discussed patch won't
> >> account for). Thus, some qualified names would be present in
> >> completions, and some won't. This is bad.
> >
> > Do you have an actual example?  AFAIU, this shouldn't happen: etags
> > only decides that an explicit tag name is unneeded when it can be
> > deduced from the pattern.  So if the explicit tag is not in TAGS, it
> > means etags.el can find it in the pattern.  (Qualified tag names that
> > are constructed by etags are never in the pattern, so they will always
> > get explicit tag names.)
> 
> I believe that the current choice is between "etags produces unqualified 
> tags" and "etags produces both qualified and unqualified tags for lines 
> where the distinction appies" (2 entries per line).

Yes.

> In the latter case the patch above is extraneous. So above I'm 
> describing the situation where etags produces unqualified tags (which it 
> currently does, by default).

OK.

> > Yes, but I'd like to make a decision before making the change for
> > placing 2 entries, so that the number of backward-incompatible changes
> > could be minimized.
> 
> I think that would be a mistake. Rather, we should make the choice based 
> on correctness.

Won't TAGS file with 2 entries for such symbols facilitate more
correct operation, both from xref-find-definitions and completion?

> >> It's harder to present a realistic case of a user looking for one thing
> >> and getting another, but the point is, is the Etags parser decided that
> >> the implicit tag doesn't match the explicit tag, we should ignore the
> >> former (because we don't really know the way they mismatch).
> >
> > I think we already do.
> 
> Currently, we don't put the implicit tag into the completion table if 
> the explicit tag is present.
> 
> But we do match implicit tags during navigation, even when an explicit 
> tag is there.
> 
> The aforementioned patch would include the implicit tag in the 
> completion table anyway. I'm now saying we don't want that, and we also 
> don't want navigation to match implicit tags in the entries that contain 
> an explicit tag as well.

Then how will you find or complete on "foo" when the explicit tag is
"XX::foo"?

Previous Next

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