bug#59381: Should xref--marker-ring be per-window?

[Dmitry Gutov]

On 19.11.2022 21:53, Eli Zaretskii wrote:
> > Ideally, making an existing variable window-local should be as easy
> > as making it buffer-local, e.g.:
> >
> >    (make-variable-buffer-local 'xref--history)
> >    ->
> >    (make-variable-window-local 'xref--history)
> >
> > But we are not here so far.
> I don't think it's that simple.  Windows are much more ephemeral than buffers;
> for example, "C-x 2" followed by "C-x 1" or "C-x 0" deletes one of the windows.
> What do we want to happen with the "window-local" xref stack in that case?

Poof. Not sure what else we could do.

> My guess is that the OP wanted to have control on when M-. pushes locations to
> the last used stack or begin a new stack.  Because only the user knows when
> M-. begins a new series of searches.  So I think it is better to offer a
> separate command for exercising just such control.

As previously mentioned in 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38797#8, I personally find 
it perfectly usable to always use window-local stacks.

But maybe it will be helpful for you to elaborate: what the workflow 
would look like. Would it be a parallel set of commands, or simply a 
command to... do what?

In my workflow, a new stack is more or less created implicitly by 
splitting a window, and discarded by deleting one. The older stacks can 
get forgotten, but while the locations are fresh in mind, this behavior 
feels logical: it *feels* that I did that chain of navigations in one 
window, and another in the other one. And I can jump back and forward in 
each one in parallel.

I suppose it doesn't work as well when commands pop new windows a lot, 
but luckily M-. doesn't do that too often.