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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> I don't understand exactly the scenario you're talking about.  Can you
>> give a recipe?
>
> Yes:
>
>   emacs -Q
>   C-x C-f lisp/simple.el RET
>   M-. find-tag RET
>
> This puts you at the first line of find-tag, without showing the other
> possible symbols whose names contain "find-tag" as their substring.

Yes, that's the expected behavior, and matches the behavior of Emacs-24.
Is that a behavior you like or a behavior you dislike?

> By contrast, this:
>
>   emacs -Q
>   C-x C-f lisp/simple.el RET
>   M-x load-library RET xref RET
>   M-x xref-etags-mode RET
>   M-. find-tag RET
>
> does NOT show the definition of find-tag, but instead opens an *xref*
> buffer with possible matches, and expects you to pick one of them (and

Indeed, one of the differences in the new UI is that we don't have the
"C-u M-. lets you cycle among matches" any more.  Instead we pop up an
*xref* buffer where you can choose the match that interests you.  I find
this easier (and generally faster) to use.

This is an issue that only affects the UI (not the API and hence not the
backends), so we can easily fix it by providing either different UIs, or
some config var, or ...

> btw the defun I'm probably after is not the first or second hit there;
> looks like the candidates are arranged in the alphabetical order of
> the *.el files).

Indeed, the ordering looks incorrect.  This is a bug.

> I guess the elisp-mode back-end returns just one candidate, whereas
> the etags back-end returns a list.

Exactly.

> But it's confusing to have such evident differences just because you
> changed the back-end, I think.

But popping up the *xref* buffer when there's only one element in it
doesn't make much sense I think.


        Stefan