GNU bug report logs -
#19468
25.0.50; UI inconveniences with M-.
Previous Next
Reported by: Eli Zaretskii <eliz <at> gnu.org>
Date: Mon, 29 Dec 2014 20:27:02 UTC
Severity: normal
Found in version 25.0.50
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
Message #395 received at 19468 <at> debbugs.gnu.org (full text, mbox):
On 05/01/2015 10:22 PM, Eli Zaretskii wrote:
> If it doesn't, it should ask the user.
That's a speed bump. Not to say that a generic symbol-browsing facility
handling different kinds of them won't be useful, but that's not what I
see `M-.' doing.
> The example is still valid. How do you know another back-end won't do
> something similar?
How do you know another back-end won't return 140 results for "function
named car"? In the end, it's up to the backend's author to write an
implementation conforming to what's being asked of it.
> 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.
There's nothing to note. While *I* can only speak for myself, Stefan
expressed a similar preference. IIRC, both Jorgen and Helmut did so as well.
Of course, I'd be happy to make it more customizable, if it can still
work well enough for me, at least in one configuration. But I'll need
more concrete design proposals on that.
> 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.
That hasn't been my experience. They do have different commands for
different searches, but those vary between editors. Yet, there's always
a "go to definition" command that tries its best not to ask the user
anything else, and jumps to wherever the symbol at point was "defined".
It's usually bound to Ctrl-Click.
> But having just one level is never right in such cases.
I wonder if it's even possible to define a set of levels in a
backend-agnostic way. For instance, for etags you have "exact matches",
"exact implicit matches", "word matches", "partial file name matches", etc.
In the Elisp backend, I'd see the "same kind of entity", "other kinds of
entities with that name", "fuzzy matches on the name".
Keep in mind though, that if we introduce the notion of levels in the
interface, it'll also complicate things for every implementor.
Maybe the solution is to define the ability for a backend to return
groups, probably nested ones.
This bug report was last modified 9 years and 149 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.