GNU bug report logs - #19468
25.0.50; UI inconveniences with M-.

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 19468 <at> debbugs.gnu.org
Subject: bug#19468: 25.0.50; UI inconveniences with M-.
Date: Wed, 29 Apr 2015 00:00:31 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.