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

[Eli Zaretskii]

> Date: Wed, 29 Apr 2015 00:33:13 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: monnier@IRO.UMontreal.CA, 19468@debbugs.gnu.org
> 
>     You could have the few "best matches" listed separately in the
>     beginning of the list, followed by the grouping shown today.
> 
> What's "best matches"? I suggested using `tag-exact-match-p' in the etags 
> backend. What's your take on this?

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

Note that I specifically didn't mention tag-exact-match-p, because of
the implicit tag name issue, see below.

>         - Should xref always try to preserve the order in which xrefs are 
> returned?
> 
>     No!  This would make the UI even more dependent on the back-ends.
> 
> 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.

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.

> What about the rest of the predicates in `find-tag-tag-order' set by 
> `etags-recognize-tags-table'? Should we disregard all of them?

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

File-name matches and word matches are only useful in specialized
searches, and partial matches are just a kind of "fire escape".