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

[Ackerley Tng <ackerleytng@gmail.com>]

On Sun, Nov 20, 2022 at 9:32 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Sun, 20 Nov 2022 19:00:49 +0200
> > Cc: 59381@debbugs.gnu.org, juri@linkov.net
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > On 20.11.2022 09:09, Eli Zaretskii wrote:
> > >> From: Ackerley Tng<ackerleytng@gmail.com>
> > >> Date: Sat, 19 Nov 2022 14:01:52 -0800
> > >> Cc: Juri Linkov<juri@linkov.net>,59381@debbugs.gnu.org
> > >>
> > >> What if we copy the whole stackv from the old window whenever a new window is opened?
> > > What will happen with that if you switch to another window which displays
> > > the same file, or delete the window where the stack is kept?
> > >
> > > And please note that results of creation and deletion of windows are not
> > > always predictable from the user POV.  E.g., when you type "C-x 2", do you
> > > always know which of the two windows will keep the ID of the original single
> > > window?
> >
> > If the stack is copied, isn't that a non-issue?
>
> It is, provided that copying is indeed what the user wants.  But how can we
> know?  A new window can be completely unrelated.
>
> And I'm more worried by window deletion than by creation.

I think Eli brought up a good point about splitting windows. Here's
the situation that is a little sticky.

1. User builds the stack up to buffer A in window 1
2. User creates a new window, so now we have buffer A in window 1 and
buffer A in window 2
3. User builds up the stack further in window 2, AND we have the
feature to navigate forwards as eli brought up, in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38797#8
4. In window 2, user navigates backwards so that now both window 1 and
2 are showing buffer A
5. User might close window 2, either confused about which stack was in
window 1 and window 2, or assuming that window 1 and 2 have the same
stacks.

Closing window 2 would be bad since the user would lose the go-forward
history. However, I feel that if the window position on screen remains
consistent, the user would be able to remember where they were
navigating, and I think they would close the right window. I feel that
for most cases this wouldn't be a problem.

I think Eli is right in saying that we will never know when the user
wants to fork a navigation stack. My issue with an explicit command is
that I would probably forget to initiate a new stack when I need to,
and by time I realize it, it would be too late to start/copy the
stack.

Also, in this new explicit command, the user will have to specify the
window to copy the stack from, and the window to copy the stack to,
which is quite a lot of steps, which would get in the way of wanting
to navigate code.

What does everyone think if we do the baseline of just creating a new
stack per-window (no copying) and then waiting to see if we get
feedback once people start using it?

I'm new to development of emacs itself, since in the debbugs link the
bug was closed and the feature pushed, are we expecting this feature
in a future version of emacs?