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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: dgutov@yandex.ru, 19468@debbugs.gnu.org
> Date: Mon, 27 Apr 2015 13:35:25 -0400
> 
> >> 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.

Emacs 24 also had "C-u M-." to go to the next one.  This one doesn't;
moreover, if you try "C-u M-.", you get prompted for the symbol again,
and if you type the same one, you get nowhere.  The other matches are
only available via completion, see below.

> Is that a behavior you like or a behavior you dislike?

It's surprising, since I expected to see the *xref* buffer, as I
understood this is the core of the new UI.  But it sounds like the
back-end can easily affect the UI in radical ways, which I think is
not a good thing: the entire idea of the back-end means to me that the
front-end is not affected, UI-wise.

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

OK, but then why aren't we shown *xref* in the first case?

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

Oh, but there shouldn't be only one element: you will see the others
if you type TAB instead of RET.  IOW, the elisp-mode back-end does
know about the other candidates, it just doesn't show them in *xref*.
It somehow decided for me that I want only the exact match.

And btw, there is another confusing difference between these back-ends
that somehow bubbles up to the UI level: the elisp-mode back-end only
supports finding multiple matches via completion, and completion, at
least by default, only finds candidates whose leading substring
matches what you type.  By contrast, the *xref* buffer popped when the
etags back-end is in use shows substring matches _anywhere_ in the
symbol names, so it shows much more candidates.