[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: 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:

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

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

These criteria are described in the xref-find-function docstring. Maybe not ideally: feel free to suggest a more clear wording.

reply via email to

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