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

From: Dmitry Gutov <[email-masked]>
Date: Tue, 28 Apr 2015 02:47:41 +0300

On 04/26/2015 05:56 PM, Eli Zaretskii wrote:

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

I don't know if we want to settle on that solution, actually. Have you 
seen this thread?

http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg01236.html

That's not so easy to wrap in a global minor mode. I'm not even sure a 
minor mode would be a good approach here at all.

However, it's a lot more flexible than using xref-etags-mode, especially 
with the changes to help buffers proposed by Daniel.

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

`M-x find-tag' behaves exactly the same: even when the result is that we 
don't move anywhere (for the same reason), there's no helpful message. 
Just "Mark set" in the echo area.

I don't know if adding a new message in this case will be too helpful, 
but you're welcome to suggest the wording.

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

I'd take a look at the patch.

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

There's also the `C-o' binding, which displays the xref, but keeps the 
current focus.

 >  I think it would be more helpful
 >         to just switch to the window showing the definition, but leave
 >         the *xref* buffer shown.

Some packages take this approach; I don't like it. But this should be 
easy to implement with a user option that would slightly change the 
behavior of `xref-goto-xref'. Care to take a stab at it?

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

Should those be `n' and `p' instead, by default? I've found myself using 
these bindings very rarely anyway, and `n' is still very close.

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

Compilation and Grep both use M-g M-n/M-g M-p, and the 
next-error-function variable. Do you want xref to reuse it?

Would you be comfortable with forgetting the current list of errors 
after navigating somewhere with xref?

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

There's also ggtags in GNU ELPA. I'm sure it could provide some 
integration, too.