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

[Eli Zaretskii]

So, prompted by the renewed discussion of 'xref', I took another look
at the current states of affairs with the UI, and found the following
issues:

 . xref-etags-mode:

   I tried this mode, and found a few places for improvement:

   . It's not available by default:

     emacs -Q
     M-x xref-et TAB => [No match]

     It should be autoloaded, IMO.  Perhaps there should also be a
     global minor mode, for those who'd like that.

   . It does nothing when point is on a unique symbol:

     M-. set_cursor_from_row RET
     Now, with point on its position under set_cursor_from_row, type
      M-. again => nothing(??!!) happens

     I guess it looks for more symbols matching set_cursor_from_row,
     finds out that this is the only one, and does nothing.  This is
     not useful.  It should at the very least say something like
     "set_cursor_from_row: this is the only match".  Bonus points for
     prompting for a symbol, like it does when there's no symbol at
     point, because I think this is more useful in this situation.

   . Some problems with key bindings in the *xref* buffer:

     . RET displays the candidate listed on the current line, but
       closes the window displaying *xref*, so it's not easy to try
       another candidate afterwards.  I think it would be more helpful
       to just switch to the window showing the definition, but leave
       the *xref* buffer shown.
     . You need to use the unconventional '.' and ',' to both move and
       display the definitions -- this should at least be mentioned in
       the initial echo-area message when *xref* is first displayed.
       (This was reported as a problem in the original report, but
       seems to be left unchanged.)

   . No replacement for tags-loop-continue:

     If I somehow let the window showing *xref* close (e.g., by typing
     RET, see above), what is the equivalent for tags-loop-continue,
     i.e. display the next candidate, without explicitly displaying
     the *xref* buffer again?  If there isn't one, please provide it,
     at least as part of xref-etags-mode.  (Other similar Emacs modes,
     like Compilation and Grep, do provide commands to move to the
     next item without first switching to the buffer that shows all
     the hits.)

 . The back-end issue:

   . Caveat: I couldn't find any documentation of back-ends, so
     perhaps I'm missing something important.  That being said...

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

   . xref.el says:

     ;; For now, make the etags backend the default.
     (defvar xref-find-function #'etags-xref-find

     But what are the alternatives, if any?  I could only find
     something related in ada-mode and in elisp-mode.  This means
     that, for example, for C/C++ and Java, etags is the only
     available back-end, and this change is currently just a different
     UI wrapping the same basic functionality?  Is there any further
     development planned for the near future?

   . The doc string of xref-find-function mentions several variants of
     invoking the function, but there doesn't seem to be any way of
     controlling that when invoking the function interactively, is
     there?  I think it would be good to be able to lookup only the
     definitions or only the references of a symbol.

HTH