[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19468: 25.0.50; UI inconveniences with M-.
From: |
Eli Zaretskii |
Subject: |
bug#19468: 25.0.50; UI inconveniences with M-. |
Date: |
Wed, 29 Apr 2015 18:46:06 +0300 |
> 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".
- bug#19468: 25.0.50; UI inconveniences with M-., (continued)
- bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/28
- bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/27
- bug#19468: 25.0.50; UI inconveniences with M-., Stefan Monnier, 2015/04/27
- bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/27
- bug#19468: 25.0.50; UI inconveniences with M-., Stefan Monnier, 2015/04/27
- bug#19468: 25.0.50; UI inconveniences with M-., Eli Zaretskii, 2015/04/28
- bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/28
- bug#19468: 25.0.50; UI inconveniences with M-., Eli Zaretskii, 2015/04/28
- bug#19468: 25.0.50; UI inconveniences with M-., Eli Zaretskii, 2015/04/28
- bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/28
- bug#19468: 25.0.50; UI inconveniences with M-.,
Eli Zaretskii <=
- bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/29
- bug#19468: 25.0.50; UI inconveniences with M-., Eli Zaretskii, 2015/04/30
- bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/30
- bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/27
- bug#19468: 25.0.50; UI inconveniences with M-., Eli Zaretskii, 2015/04/28
- bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/28
- bug#19468: 25.0.50; UI inconveniences with M-., Eli Zaretskii, 2015/04/29
- bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/29
bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/27
bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/27