[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59381: Should xref--marker-ring be per-window?
From: |
Eli Zaretskii |
Subject: |
bug#59381: Should xref--marker-ring be per-window? |
Date: |
Sun, 20 Nov 2022 09:59:25 +0200 |
> 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?
- bug#59381: Should xref--marker-ring be per-window?, Ackerley Tng, 2022/11/19
- bug#59381: Should xref--marker-ring be per-window?, Juri Linkov, 2022/11/19
- bug#59381: Should xref--marker-ring be per-window?, Eli Zaretskii, 2022/11/19
- bug#59381: Should xref--marker-ring be per-window?, Dmitry Gutov, 2022/11/19
- bug#59381: Should xref--marker-ring be per-window?,
Eli Zaretskii <=
- bug#59381: Should xref--marker-ring be per-window?, Dmitry Gutov, 2022/11/20
- bug#59381: Should xref--marker-ring be per-window?, Eli Zaretskii, 2022/11/21
- bug#59381: Should xref--marker-ring be per-window?, Ackerley Tng, 2022/11/21
- bug#59381: Should xref--marker-ring be per-window?, Dmitry Gutov, 2022/11/23
- bug#59381: Should xref--marker-ring be per-window?, Dmitry Gutov, 2022/11/24
- bug#59381: Should xref--marker-ring be per-window?, Ackerley Tng, 2022/11/24
- bug#59381: Should xref--marker-ring be per-window?, Dmitry Gutov, 2022/11/24
- bug#59381: Should xref--marker-ring be per-window?, Ackerley Tng, 2022/11/24
- bug#59381: Should xref--marker-ring be per-window?, Dmitry Gutov, 2022/11/24
- bug#59381: Should xref--marker-ring be per-window?, Dmitry Gutov, 2022/11/23