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

[Dmitry Gutov]

On 04/28/2015 06:00 PM, Eli Zaretskii wrote:

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

About replacing xref-etags-mode entirely, and using advice to use tags 
wherever elisp-xref-find is used.

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

Um, yeah, it would work, if you want xref-etags-mode in *all* buffers at 
all, including those that might use yet another different backend.

Actually, it still looks a good option for you, AFAICT.

> How is the old UI relevant here?  We are talking about the new UI.

We need something to compare to. If I compare it to a popular IDE, they 
usually have this functionality bound to Ctrl-Click. If there's just one 
match, the user is taken to its location, if there are several, a 
context menu is shown. No message about the only match.

Which makes sense to me.

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

Where in the old UI you could go to the next match, in the old UI we 
display the xref buffer with all matches. Where this buffer is not 
displayed, in the old UI you wouldn't have been able to the next match.

> I thought I already did, see above.

Okay, sorry. It doesn't sounds like a good idea to me anyway. Especially 
when, in many environments (like Elisp), finding only one match will be 
the norm, not exception.

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

They could also use winner-mode, or switch to *xref* manually.

Where in the documentation would you mention the key bindings?

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

I'll wait for a stronger "yes" on this.

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

We've already taken up its binding, and since showing the whole list is 
a replacement for the "show first, allow to iterate through the rest" 
logic, we're unlikely to use a new binding for the `tags-loop-continue' 
equivalent.

The next-error commands might make sense for what you're asking, as long 
as we've all considered the interaction with other commands that set 
next-error-function.

> > Would you be comfortable with forgetting the current list of errors after 
> > navigating somewhere with xref?
>
> No, I don't think so.

But that what happens if you run a compilation (with errors), and then 
call Grep. Doesn't it?

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

Nope. It remains to be written.