GNU bug report logs -
#20629
25.0.50; Regression: TAGS broken, can't find anything in C++ files.
Previous Next
Reported by: "Jan D." <jan.h.d <at> swipnet.se>
Date: Fri, 22 May 2015 05:59:02 UTC
Severity: normal
Found in version 25.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #242 received at 20629 <at> debbugs.gnu.org (full text, mbox):
>> 1) explicit tag name
>> 2) implicit tag name (unnamed tag whose name can be deduced from pattern)
>> 3) no tag name (unnamed tag)
>>
>> In some languages, like C++ and derived, most tags are named. In
>> others, most are unnamed, usually in the simplest languages.
>
>It seems we don't have a suitable predicate for unnamed tags. How does
>one determine whether an entry contains a entirely unnamed tag, or an
>implicitly named one?
If you look for an implicit name and you can't find one, then it's an
unnamed tag. This is the rule of thumb. In theory, it is not rigorous,
but in practice I think it always works.
I'll rewrite the rest now that I think I have better understood what you
need.
There is no possible comparison between an explicit and an implicit
name. A tag is named or unnamed. If it is named, whether the tag is
explicit or implicit it is only a matter of optimisation. You can't
have the choice between an explicit and an implicit name for a tag:
either you have a name or not.
My description of the flow used when looking for a tag supposed that you
are satisfied when you find a match. If instead you look for all the
matches at once, for example because you want to show them all, you
should match against all tag names first (whether the name is implicit
or explicit should not matter): those are the best matches. Next come
the matches against the patterns, which are of lower quality.
In order to find all the matching names, you make two passes, one
against tags with names: in that case you match against the explicit
names; then one against tags without names: in that case you match
against implicit names. All the matches found in the first and second
pass should be treated equally.
This bug report was last modified 9 years and 69 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.