Re: tags-loop-continue

[Eli Zaretskii]

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Thu, 14 Jan 2016 21:44:03 +0300
> 
> On 01/14/2016 09:31 PM, Eli Zaretskii wrote:
> 
> >> Why not let the user call dired-do-search, and then press `r'?
> >
> > Because people who used to have 'Q' will want to press it and get what
> > they are used to, I guess.
> 
> Ok. If you insist, I can make a version of the same logic that would 
> skip generating the output buffer.

I just want the people who are used to 'Q' to have something similar
to what they knew before.  It might be okay to show *xref*-style
buffer with the hits, though.  Is that what you meant by "press 'r'"?

> > IOW, I think we should avoid gratuitously breaking backward
> > compatibility.  Can we have faithful emulations of these commands' UI,
> > bound to the same keys, just working differently under the hood?
> 
> We could, I suppose.
> 
> But that wouldn't remove the need for tags-loop-continue, would it? Or a 
> command just like it.
> 
> And I really want to use the M-, binding for xref-pop-marker-stack.

Why is it so important to use that particular binding for
xref-pop-marker-stack?  What's wrong with 'M-*'?

> - Do we create versions of all new commands that use the traditional 
> interface?

No, not necessarily.  They should be functionally equivalent and
similar enough in principle.  They don't have to have the same
interface.

> - If not, do we have similar commands that use different presentations? 
> Do we reflect the distinction in their names? How? For now, we're 
> calling the new UI also xref, but it conflates it with the core xref 
> infrastructure (backends and "smart" IDE-ish commands).

For lack of a better name, I guess.  The old one was called "etags"
for the same reason, and had the same problems.

> Either way, it seems prudent to extract the current UI part of xref to a 
> package with an appropriate name.

You will still have the problem of coming up with a suitable name ;-)