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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 20 Nov 2022 04:52:38 +0200
> Cc: ackerleytng@gmail.com, 59381@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> > 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?

I just did that, above: add a command that starts a new "stack".  All the
rest is unchanged.

> In my workflow, a new stack is more or less created implicitly by 
> splitting a window, and discarded by deleting one.

So you always ever have a given buffer displayed in a single window?  Does
it ever happen to you that you need to work on one portion of a file while
looking at its another portion? or work on one file while look at another
file in a sibling window?  If you ever need to do these, and both windows
show files that belong to the same "editing activity", why would the stack
be local to a window?  That would effectively designate a single window as
the only one where M-. and M-, will do what you expect, no?

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

But not if you switch windows?

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

In your experience, maybe.  In Emacs we have macros like FOO_BAR that call
functions named foo_bar, and then M-. always pops up a new window.  Likewise
with macros or data structures that have several different definitions
depending on the window-system backend (X, w32, NS, etc.).

The use cases I described don't work well with window-local stacks.  So if
an explicit command as I envisioned is deemed an annoyance, perhaps a user
option which will allow one or the other workflow is in order?