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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 19468 <at> debbugs.gnu.org
Subject: bug#19468: 25.0.50; UI inconveniences with M-.
Date: Fri, 01 May 2015 21:38:01 +0300

> Cc: 19468 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> 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.

Previous Next

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