bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: 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@yandex.ru>
> CC: 19468@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]