[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: |
Wed, 29 Apr 2015 00:00:31 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 |
On 04/28/2015 05:48 PM, Eli Zaretskii wrote:
By
contrast, the new UI is inconsistent: with some back-ends it shows the
list of matches and allows to navigate it, with others it shows only
the first match and does not give any way to get the next match.
The UI has nothing to do with it. It's just the etags backend often
returns multiple results to the "find-definitions" command.
The elisp backend is more precise, but it can also return multiple
results under certain conditions. For instance, when the exact name
we're looking for corresponds to a function, a feature name, and a face
(there's certain effort there not to show both a function and a variable
with the same name, because they usually both point to a minor mode
definition).
No: there's only one definition of `find-tag' so Elisp's xref backend
just returns that one and that's it.
There's more than one matching definition, see below.
If you want "matching" definitions, use xref-find-apropos.
But that's largely immaterial: this bug report is not about the
back-end, it's about the UI. The UI should be independent of the
back-end, otherwise the users will be confused when they switch
between languages.
The UI can only work with that a backend returns to it. A non-ideal
implementation can result in non-ideal behavior in the end.
(If it turns out that some back-ends need to be
augmented so that they allow the front-end to present similar UI for
the same query, then those back-ends should be enhanced.)
Sure. I'd be happy to leave that to someone else, but there doesn't seem
to be someone actively maintaining it.
In that situation, we first try to make the backend work as well as
`find-tag'. Patches, as well as specific technical suggestions, are very
welcome.
Arguably, the find-tag advice in org-ctags.el could be offered as well,
if org-ctags.el happens to be loaded
??? Why should the xref matches depend on what is and isn't loaded?
The above is referring to the Elisp xref backend, which is based on the
package `find-func'. Which, yes,
That would make xref exactly equivalent to "M-x apropos", which means
this mode of operation would make xref entirely redundant.
I don't know how to respond to this. Yes, they use the same data
available at runtime. No, they're not exact duplicates of each other;
the data is used in slightly different ways and presented in a different
interface.
To say
nothing of the fact that this doesn't scale to any language except
ELisp.
Yes, the Elisp backend doesn't scale to other languages.
(One of my worst annoyances is to type a
C-h command and be presented with "[No match]", because some package
is not loaded or some function is not available in the Emacs
configuration I happen to be using.)
It's the cost of doing business, as far as I'm concerned. You can't use
tags for non-core Elisp code anyway, such as anything in your init
directory (installed packages, etc), and any Elisp files installed
separately by the operating system's distribution.
Actually, if you're not working on a Git checkout, I don't think you can
use the tags even for the Elisp code that's part of Emacs.
The important point for the purposes of this bug report is that the
stuff presented by the UI for the same query does not differ so
radically when you switch the back-end.
In general, it's the concern of each particular backend, to adhere to
the described interface. The UI has nothing to do with it.
. there should be a way to go to the next/previous match if the
*xref* buffer is not displayed (or not created in the first
place); if this happens because there's only one match, we should
say so explicitly
I don't see the point. That fact that we've jumped to a new location
means there was a match, and since we haven't seen the xref buffer,
there were no other matches.
The message might feel assuring to you in the beginning, but over time I
think it'll just become a nuisance.
. when there are more than one possible match, the UI should behave
similarly, i.e. display the *xref* buffer; when there's only one
match, it should _never_ display *xref*,
That's how it works already. With the exception of the "possible match"
phrasing, which is nonsense to me. There either are matches of the kind
that the current command is asking for, or there aren't.
. if the criteria for filtering of the matches are very different
between the possible back-ends, there should be some agreed-upon
uniform default that returns roughly the same number of matches
with all back-ends, and the rest should be controlled by user
options
These criteria are described in the xref-find-function docstring. Maybe
not ideally: feel free to suggest a more clear wording.
- bug#19468: 25.0.50; UI inconveniences with M-., (continued)
bug#19468: 25.0.50; UI inconveniences with M-., Eli Zaretskii, 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/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-., 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 <=
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-., Eli Zaretskii, 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-., 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-., Dmitry Gutov, 2015/04/27
bug#19468: 25.0.50; UI inconveniences with M-., Stefan Monnier, 2015/04/28
bug#19468: 25.0.50; UI inconveniences with M-., Dmitry Gutov, 2015/04/28