bug#31027: 27.0.50; xref, tags-location-ring equivalent

[Charles A. Roelli]

> Cc: 31027@debbugs.gnu.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 6 Apr 2018 00:05:01 +0300
> 
> On 4/5/18 9:56 PM, Charles A. Roelli wrote:
> > Anyway, I suggest we follow the etags implementation of
> > "tags-location-ring".  This is all there is to it, in simplified
> > terms:
> 
> You mean, supporting a negative argument to xref-find-definitions? 

Yes.

>                                                                    As 
> well as successive invocations that move between matches?

Successive invocations wouldn't be handled specially, I think; they
would just show entries further back in the location ring.

> Not sure we really want to do that: after all, the xref interface 
> already provides the means to select among the locations.

Can you clarify what you mean by this?  How can I use xref to navigate
among the N previous locations that have been jumped to?  If that
functionality already exists, then this discussion is moot.

>                                                           And we have 
> previous/next-error

It's difficult to say whether "next-error" can do what this request is
asking for, when "next-error" and its relation to xref have yet to be
defined.  From what I can see, it looks like a different ball game.
For example, the doc of "next-error-function" says it's the

  Function to use to find the next error in the current buffer.

But this request is asking for a way to navigate among the locations
jumped to in any buffer, not just one.  Additionally, there's no
guarantee that the "next' or "previous error" in the current buffer
would happen to coincide with the previous location jumped to
globally.  I don't see how those two things relate to each other,
since an "error" can be one of many different things: a compiler
error, a search result, a changed part of a buffer, or with the xref
package, a symbol definition.  The scope of "errors" is very broad.