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

[Eli Zaretskii]

> Cc: 19468@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 1 May 2015 17:51:14 +0300
> 
> On 05/01/2015 03:57 PM, Eli Zaretskii wrote:
> 
> > Sorry, I don't understand what "Elisp environment at runtime" means in
> > practice, or how it's used to affect what results are returned for a
> > query.
> 
> find-func knows about defined functions and defined variables. 
> elisp-mode knows that a function usually goes after a paren, and a 
> variable - after a space (to simplify things).
> 
> Thus, elisp-xref-find could narrow the search space based on whether 
> there is a paren before the symbol at point (we don't do that, partially 
> because the situation is more complicated; but we should, in the 
> future). A language-agnostic UI won't ever be able to do so.

A language-agnostic UI could well ask the back-end for variables, or
for functions, or for both, or whatever.

Like I said: some functionality must reside in the back-end, but the
UI must control it, instead of blindly trusting its defaults.  When we
blindly trust the defaults of each back-end, we get what triggered
this discussion, because etags' default is to produce a 140-long list
of potential matches, which elisp-mode's xref default is to produce
only one.  In most of my use cases, neither is TRT.

> > That's the case where the UI should instruct the back-end what it
> > needs, because the back-end doesn't know which of these alternatives
> > is the right one.  If the user wants all bar functions, or maybe those
> > whose parent class matches some regexp, not just the one from the
> > class instance at point, then producing only one match would be wrong,
> > and the UI won't be able to correct that.
> 
> If the user calls xref-find-definitions, we consider that to see the 
> definition of the function called at point (or definitions, if virtual 
> dispatch is unavoidable, such as in case of a Java interface, and there 
> are several options), but not more.

We shall never second-guess the user.  I already described an
important class of use cases where this assumption is simply wrong.
It shouldn't probably even be the default.

> For more lax matching options, the user will call xref-find-apropos.

It's an annoyance to have to use more than one command for a single
purpose.