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

[Dmitry Gutov]

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

> It seemed to show both qualified and unqualified names, AFAICS.

I'd rather the comparison was made when TAGS is using 2-lines-per-item. 
Having two different ways to obtain the qualified names doesn't sounds 
good to me, and using implicit tag names is faulty:

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

- See below (*).

> > Err, these changes are orthogonal, if not to say complete opposites. If
> > there are two lines in TAGS for each item, no change to
> > etags-tags-completion-table should be necessary.
>
> The question still stands.

It's only the question of the default behavior that's still undecided. 
The user will have a way to see qualified names either way.

> But tag-implicit-name-match-p is called after tag-exact-match-p, so
> the latter cannot be the fallback for the former.

I'm not sure what you mean. Why fallback?

(*)

Consider this: if the explicit tag name is present, then the tag name we 
can guess from the pattern implicitly is _incorrect_, so it's wrong to 
match it.

For instance, visit lisp/TAGS and try to navigate to "'edit-abbrevs-map" 
(yes, including a quote). There will be a match, but it was in fact a 
faulty search: an Elisp identifier can't include a quote.

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