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

[Eli Zaretskii]

> Date: Tue, 28 Apr 2015 02:47:41 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 19468@debbugs.gnu.org
> 
>           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

Yes, but I'm unsure how is that relevant.  Are you talking about
auto-loading, or are you talking about a global minor mode?

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

Sorry, you lost me.  What aspects prevent us from making a global
minor mode that uses xref-etags-mode in all buffers?

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

How is the old UI relevant here?  We are talking about the new UI.  (I
already explained elsewhere that the old UI had "C-u M-." to go to the
next match, whereas the new UI provides the *xref* buffer for that
instead.  So what the old UI did in this situation is not relevant,
because the crucial feature of going to the next match, which was part
of dealing with this situation in the old UI, is missing in the new
UI.  Thus, the new UI should find a different solution for this
situation.)

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

I thought I already did, see above.

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

OK (did I say the documentation is missing?), but RET is the usual way
of doing this, so I guess many users will.

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

Maybe, if/when I have time.  The more important issue is how to go to
the next candidate once the window showing *xref* is closed.

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

Possibly.

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

Something like that, yes.  There's also "C-x `".  Or maybe you should
bring the equivalent of tags-loop-continue back ;-)

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

No, I don't think so.

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

I don't see any xref-related code in ggtags.  Did I miss something?