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

Previous Next

Full log

Message #227 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: monnier <at> iro.umontreal.ca, 19468 <at> debbugs.gnu.org
Subject: Re: bug#19468: 25.0.50; UI inconveniences with M-.
Date: Tue, 28 Apr 2015 17:49:55 +0300

> Date: Tue, 28 Apr 2015 01:09:40 +0300
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: 19468 <at> debbugs.gnu.org
> 
>     This puts you at the first line of find-tag, without showing the other
>     possible symbols whose names contain "find-tag" as their substring.
>     If you want the other candidates, you need to type TAB instead of RET,
>     and then select the one you want via the usual completion facilities.
> 
> Yes, if you want all matches, try `xref-find-apropos' (bound to `C-M-.').

Some would say it's a disadvantage to need another command.  It means
the user has to decide up front which one she needs.  Showing the rest
of matches after the exact one doesn't have this disadvantage.

Once again, this bug is about the UI.  The UI shows only one match
with one back-end, and all of them with another.  That's the problem I
think we should address.

>     I guess the elisp-mode back-end returns just one candidate, whereas
>     the etags back-end returns a list.  But it's confusing to have such
>     evident differences just because you changed the back-end, I think.
> 
> etags showing all matches is, in general, the limitation of the tags file format.

??? How can what we show be the limitation of the format of the
database where we keep the data?  If we think we should not display
everything, let's filter the irrelevant stuff before showing it.

> But if someone submits a patch making it more precise without creating false negatives, I'm all for it.

I'd generally expect the people who worked on a feature and lobbied
for its introduction to be the ones who work on such significant
issues with that feature.  But if not, I hope that someone
materializes soon.

> And hey, you changed the back-end. It uses a different mechanism under the covers. *Of course* you're going to get different results, in many cases.

I changed the back-end, not the UI.  The UI should not depend on the
back-end so much -- this is what this thread is all about.  I'm okay
with getting slightly different results, and I'm okay with having user
options to control the amount of filtering so that I could get
significantly more or less results when I need that.

But presenting such widely different results _by_default_ is a
terrible usability problem.  Just imagine a user who needs to switch
languages.

Previous Next

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