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

[Eli Zaretskii]

> Date: Wed, 29 Apr 2015 00:00:31 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 19468@debbugs.gnu.org
> 
>         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.

That's a UI inconvenience, IMO.  I already explained why: it requires
me to know up front whether the symbol name I'm about to type is
precise or not.

>     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.

We should not have "non-ideal" implementation that return radically
different results.  Each query by default should yield approximately
the same result.  If the differences are small, or differ only in
their order, that's OK.  But having one list of results be 2 orders of
magnitude larger than another is something to avoid at all costs.

>     (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.

That kind of thing happens every day in Emacs development, IME.
There's no way around it, if you care about some component, and
another one gets in the way, you need to fix that other component.

> > 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.

I wasn't talking about the elis backend, I was talking about the
design principles.

>     (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.

No, it's a bug to be fixed.

> 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.

Of course I can use TAGS: I just need to load those additional tags
tables.

> 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.

Why not?  I do it all the time, and tried again just now: it works.