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

[Eli Zaretskii]

> Cc: 19468@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 1 May 2015 23:36:31 +0300
> 
> On 05/01/2015 10:22 PM, Eli Zaretskii wrote:
> 
> > If it doesn't, it should ask the user.
> 
> That's a speed bump.

Yes.  But the alternative, of producing output that the user deosn't
want, or no output at all, is worse, don't you think?

> 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.

Yes, but the specification to which it should conform should be more
detailed, otherwise some back-end could very well claim conformance
and still produce such large lists.  The restrictions, such as "only
exact matches" or "only functions" etc. should be a necessary part of
the API -- then and only then would it be possible to reject a
back-end that returns 140 hits for "exact matches only" query.

> > 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.

So at best you have 80% of users that would want the same as you.
What about the other 20%?  Shouldn't we provide customizable options
for them, even though they might be a minority?

> 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.

My proposal was to come up with types of matches (I mentioned them
already several times), and then let the users customize the
collection of types passed to the back-end by default.  Whether this
translates immediately to some design, I don't know, although it
seemed to me it does.

> I wonder if it's even possible to define a set of levels in a 
> backend-agnostic way.

I think it is.

> For instance, for etags you have "exact matches", 
> "exact implicit matches", "word matches", "partial file name matches", etc.

Except for "implicit matches" that should actually be part of the same
generalized class as "exact matches", the rest are quite general, I
think.

> In the Elisp backend, I'd see the "same kind of entity", "other kinds of 
> entities with that name", "fuzzy matches on the name".

"Fuzzy" is "substring" in etags, "same/other kinds" should be
translated to "functions/variables" etc.

> Keep in mind though, that if we introduce the notion of levels in the 
> interface, it'll also complicate things for every implementor.

The goal is to provide a better user experience, not to make life
easier for the implementors.

But if a certain back-end can do a good job by implementing only one
level, into which all the levels will map, then it's an okay solution
for that back-end's targets.