>> Whatever we did here, it would make `switch-to-buffer' behave
>> inconsistently.
>
> But it'd be the natural thing to do, I think.
I can't tell because I'm a single-frame user. The main argument in
favor of a "retain the previous point" strategy is that it makes no
sense to go to the same position already shown in another frame. But
then what about doing C-x b in a window below another one already
showing the buffer I want to switch to?
This is an interesting question. The behavior today closely parallels
the multi-frame behavior, so I can see how you feel that making my
proposed change would make `switch-to-buffer' inconsistent.
But you have reminded me that I have for many years wished for the
multi-window-one-frame behavior to be different -- and in essentially
the same way I've proposed that the multi-window-multi-frame behavior
be changed.
Assume you have buffer B open on frame F in windows T, U and V,
respectively displaying B at positions P1, P2 and P3. Now in window
W, also on F, you C-x b to switch to B. Today it takes you to P1,
assuming T is next in the window-list. If no window were currently
showing B, then W would display point-min.
Let's call this the "existing-window" behavior, as for a new window W it
will choose a position from an existing window. If you were to make my
proposed multi-frame change, I think you could reasonably choose to
retain the existing-window behavior within a frame, as it preserves the
current intra-frame buffer-switching semantics.
However, over the decades I have noticed that when I have two or
more windows open to the same buffer on the same frame, it is almost
always because I want to establish N > 1 persistent working locations
within that buffer. In fact it is rarely useful to have two windows open
to the same buffer location, as they merely echo each other. So
I would posit that my "multiple persistent working locations" use case
is likely to be the most common reason for users to have N > 1
windows displaying the same buffer in a given frame.
The problem with today's "existing-window" behavior is that if you
have window T displaying buffer B on frame F at buffer position P,
then you can not sustain a *persistent* working location P' in any
other window U on F. By "persistent", I specifically mean that in
window U, if I switch temporarily away to another buffer and then
back, I want to go back to P'. Today it takes me to P: I have lost
my working location in U.
I have long found this behavior most unfortunate. Ironically, the
best workaround is to visit B in window X on a second frame G.
Then no matter what happens to the window configuration in F,
X will retain its window point at your second working location P'.
Trying to work around it within F requires that you disturb your
window configuration, or attempt to track your working locations
with the mark ring, or some other relatively unnatural workflow.
At least, I find it unnatural compared to my desired workflow:
- open a window T and display buffer B at position Pt
- in window U switch to buffer B (it defaults to Pt, which is fine)
- then in U:
* move to a different position Pu in B
* switch to any other buffer C (e.g. Info, shell, ...)
* switch back to buffer B
* continue working at Pu
This workflow, which I think of as "persistent window positions",
would actually be closest to how Emacs works in the most
common use case of all: single-frame, single-window. If you are
visiting B at position P, and you switch away, then back, you will
return to P. It is easy to think of this as the window remembering
where you last were in B. If you think of it this way, as I do, then
you are constantly surprised that windows suffer from amnesia
whenever more than one of them is displaying the same buffer.
It feels to me that they should behave as if they are independent.
Thus I would be happiest if there were an option such that every
window tracks the buffer positions of every buffer that it visits,
and when switching back to a buffer B that it has already visited,
each window displays B at the same position it last displayed B.
If you kill a window, its position list goes away. New windows
would start with a nil position list, and the first time they visit a
buffer they would use the "existing-window" semantics: use
the position of the next window currently displaying the buffer,
or else point-min. (It might be confusing to have them choose
from the position-list of a window that has previously visited
the buffer but is not currently displaying it, so I'd not do that.)
Similarly if you kill a buffer, then it is removed from the position
lists for all existing windows. If it is recreated, e.g. by opening
the file again for file buffers, all windows would initially begin
viewing it at point-min.
I think "per-window visited-buffer last-position lists" would solve
the multi-frame problem (4041). I believe they would also
clean up the IMO rather unfortunate existing semantics for
same-buffer, same-frame, multiple windows, since the current
behavior (a) doesn't parallel the current single-frame, single
window behavior, and (b) doesn't allow for multiple temporary
"persistent" working locations in multiple windows in a single
buffer on a single frame.
At the very least it'd be a nice global configuration option.
I'm sure you could probably do all this with a package, but
it's fairly fundamental -- it would be nice, for example, to be
able to enable it by setting a single variable on someone
else's Emacs instance while debugging something for them.
I have done an exhaustive survey of everyone sitting near
me right now, and they both agreed that buffer positions
should be "window-local", and that they've been annoyed
by it forever as well. Just wanted to cover my bases! ;)
-steve