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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  19468@debbugs.gnu.org
> Date: Mon, 27 Apr 2015 00:30:41 -0400
> 
> >    . I tried the ELisp back-end and found that it somehow affects the
> >      UI, so that the UI behaves differently than with the default
> >      etags back-end, when the user types something that is "complete,
> >      but not unique": when using the etags back-end, Emacs displays a
> >      list of candidates in the *xref* buffer, whereas with the
> >      elisp-mode back-end it shows the "complete" candidate, doesn't
> >      display *xref*, and doesn't insert the other candidates into
> >      *xref*.  Is this difference intended?  It's confusing, to say the
> >      least.
> 
> 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.
If you want the other candidates, you need to type TAB instead of RET,
and then select the one you want via the usual completion facilities.

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

I guess the elisp-mode back-end returns just one candidate, whereas
the etags back-end returns a list.  But it's confusing to have such
evident differences just because you changed the back-end, I think.