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

Previous Next

Full log

Message #392 received at 19468 <at> debbugs.gnu.org (full text, mbox):

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

> Cc: 19468 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 1 May 2015 21:44:12 +0300
> 
> On 05/01/2015 09:38 PM, Eli Zaretskii wrote:
> 
> > A language-agnostic UI could well ask the back-end for variables, or
> > for functions, or for both, or whatever.
> 
> Why would it ask about "functions". How would it know about functions, 
> or that we want a function right now?

If it doesn't, it should ask the user.

> > 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 is no longer true. You should build the current master.

The example is still valid.  How do you know another back-end won't do
something similar?

> > It's an annoyance to have to use more than one command for a single
> > purpose.
> 
> By default, I don't want to see the list at all, most of the time, just 
> jump to the only match. We won't have that if xref-find-definitions is lax.

Note the "I" vs the "we".  If _you_ want to see only one match most of
the time, you should be able to customize the feature to do just that.
Others could customize it differently, according to their use cases.
It will still be the same command, though.

Other IDEs ask the user explicitly to specify how wide she wants the
search and how detailed the results.  We could do that as well,
although I think it's less Emacsy.

But having just one level is never right in such cases.

Previous Next

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