[Top][All Lists]

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

bug#19468: 25.0.50; UI inconveniences with M-.

From: Dmitry Gutov
Subject: bug#19468: 25.0.50; UI inconveniences with M-.
Date: Thu, 30 Apr 2015 01:56:40 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

On 04/29/2015 06:46 PM, Eli Zaretskii wrote:

I'd suggest first an exact match, followed by any matches that are
exact but for letter-case.

I think we've settled on "only exact matches" (to the best of backend's ability) for xref-find-definitions.

However, in xref-find-apropos we shouldn't like the exact matches that much, and likely care about all matches. In that command's output we could use the order in which etags returns its results.

Without using the order, in which matches are returned by the backend, we can't even know 
what the "best matches" are.

Of course, we can: see above.

The backend can. The UI can't, thus far (unless only the best matches are returned to it).

Moreover, ideally the API to the back-end should allow the UI to
control the matches applied by the back-end, so that the UI gets only
the matches it wants in the first place.

Would you like to describe it in more detail? The current main options are: "give me matches for this name" and "give me matches for this regexp". There's nothing that would correspond to find-tag-tag-order.

Not sure what is included in "the rest".  For example, I don't think
it makes sense to disregard tag-implicit-name-match-p, since many tags
don't have explicit names.


In general, I think it would be good to have a user option that
controls which predicates are used by the etags back-end.  I think we
should group the predicates into meaningful groups (e.g., it makes no
sense to use tag-exact-match-p without tag-implicit-name-match-p).
The default list of the predicates should IMO include these:

   tag-exact-match-p tag-implicit-name-match-p tag-symbol-match-p

See the newly added defvar `etags-xref-find-definitions-tag-order'.

The last element seems a bit too lax to me, but it's up to you.

reply via email to

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