[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: bug#20629: 25.0.50; Regression: TAGS broken, can't find anything in C++ files.
Date: Sat, 30 May 2015 16:42:57 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]