GNU bug report logs -
#59381
Should xref--marker-ring be per-window?
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 2 years and 236 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.