Re: tags-loop-continue

[Eli Zaretskii]

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Thu, 14 Jan 2016 22:15:21 +0300
> 
> 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.

Could be fine, I think.  We did change this in find-definition, so
maybe making a similar change in Dired is okay as well.

> > 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 `,'.

When I use these commands, I don't really go back and forth that way.
In fact, I need to use M-* only rarely.

> And really, the xref UI doesn't need it.

As long as the *xref* buffer is displayed, it doesn't.  But once it is
buried, there's no easy way to go to the next hit, right?

> We should commit to one default paradigm of behavior.

I think I agree.

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

I don't know, to present a reasonable UI for an equivalent
functionality?