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

[Dmitry Gutov]

On 20.11.2022 09:59, Eli Zaretskii wrote:

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

What would happen with the current stack, though? Does it get "stashed" 
at the top of "stack of stacks", switching the current global stack 
entirely? Until we decide to "pop" to the previous stack, that is 
(another new command).

Or does it apply to the current window? What about the windows split 
from it? What about older windows we decide to pop-to-buffer to from one 
of the new windows?

You make some good points down below, I just don't see how a new command 
is going to solve the raised issues entirely.

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

Not necessarily, no. If it's a big file, I can have two parallel 
"investigations" going on in two different window on it. Using two 
different navigation stacks. That's a feature.

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

Sure.

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

More-or-less-ish.

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

Yup.

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

Whether M-. pop a new window, or you use project-find-regexp, we usually 
make sure that after you navigate to a location, it's displayed in the 
same window the search was made in. Unless the user called something 
like xref-find-definitions-other-window, naturally.

So it's generally possible to stay within the same window most of the time.

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

Sure, it should be optional. I'd like to ensure that the new workflow 
can be helpful for as many users as possible nevertheless.

And you make good points: Emacs often makes you go from a window to a 
window, reusing older windows as well. So I'm not sure how to solve that 
better: searching the window hierarchy won't help.

So it could be some propagation mechanism working when windows are split 
or buffers get displayed, which would nevertheless leave a window when 
the user pressed 'q', for instance. Reverting the window to its previous 
stack, let's say. And as for separate command, using it explicitly by 
itself is easy to forget, but it perhaps could be added to some other 
commands by the user (via before-advice or etc), to mark the beginning 
of each stack.

This is a very rough idea. There's nobody to work on it in the near 
future, I'm afraid, so adding an optional change in behavior to use 
window-local storage is probably the best way forward. To get feedback, 
as Ackerley said.