Re: tags-loop-continue

[Dmitry Gutov <dgutov@yandex.ru>]

On 01/14/2016 10:02 PM, Eli Zaretskii wrote:

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

Then they can call `next-error' instead. Unfortunately, this facility is 
unreliable in the presence of different next-error-function's in target 
buffers. But that was before xref came along.

> Is that what you meant by "press 'r'"?

I just mean that we don't have to have a separate command outside of 
search results buffer. Yes, it's unfamiliar, but the functionality is 
covered, and the manual will tell the user needs to do.

`r', pressed in an project-find-regexp output buffer, will call 
xref-query-replace. Which, yes, is currently implemented using 
`perform-replace', but that should change.

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

SLIME has shown that it's better. M-* is much farther from M-., and you 
can't as quickly navigate back by keeping M pressed, releasing `.' and 
pressing `,'.

And really, the xref UI doesn't need it. We should commit to one default 
paradigm of behavior. (If we had customizable switching between the old 
and the new UIs, we'd introduce a minor mode that would also change the 
global bindings).

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

What are the requirements, then?

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

Yes, ugh. But now we have two different UIs, so the issue is more 
pressing, unless we're content on altogether migrating off the old UI.

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

Also yes.