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

[Dmitry Gutov]

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.