bug#4041: 23.0.92; Emacs 23: buffer point is no longer frame-local

[martin rudalics <rudalics@gmx.at>]

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

Hardly.  It takes you to P1 because presumably window T is selected and
the window point of the selected window usually coincides with that
window's buffer's point.

 > If no window were currently
 > showing B, then W would display point-min.

Hopefully not.  W should display the buffer's `point' (which, if the
buffer was never shown before, would coincide with `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.

Not necessarily.  If another window were selected and, in B you go to
some other position, the next `switch-to-buffer' will display B around
`point' which might not coincide with any of the other windows'
positions.

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

Having "two or more windows open to the same buffer" sounds like a
reasonable condition.  The problem is that you might have no window
showing the buffer and still want to restore the previous window
position.  That's why `switch-to-prev-buffer' is superior to any
`switch-to-buffer' changing solution.  Notwithstanding Lars' argument
that people are used to C-x b, tell me why `switch-to-prev-buffer'
(combined with `switch-to-next-buffer') doesn't do what you want.

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

Not with `switch-to-prev-buffer' ;-)

 > 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

This should be `switch-to-prev-buffer'.

 >     * 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,

You can get these positions via `window-prev-buffers'.

 > 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! ;)

All this has been implemented - see section 28.14 Window History in the
Elisp manual.  If you still insist on having C-x b return to the
previous position, try the definition below.

martin

(defun switch-to-buffer (buffer-or-name &optional norecord force-same-window)
   "Switch to buffer BUFFER-OR-NAME in the selected window.
If called interactively, prompt for the buffer name using the
minibuffer.  The variable `confirm-nonexistent-file-or-buffer'
determines whether to request confirmation before creating a new
buffer.

BUFFER-OR-NAME may be a buffer, a string \(a buffer name), or
nil.  If BUFFER-OR-NAME is a string that does not identify an
existing buffer, create a buffer with that name.  If
BUFFER-OR-NAME is nil, switch to the buffer returned by
`other-buffer'.

Optional argument NORECORD non-nil means do not put the buffer
specified by BUFFER-OR-NAME at the front of the buffer list and
do not make the window displaying it the most recently selected
one.

If FORCE-SAME-WINDOW is non-nil, BUFFER-OR-NAME must be displayed
in the selected window; signal an error if that is
impossible (e.g. if the selected window is minibuffer-only).  If
nil, BUFFER-OR-NAME may be displayed in another window.

Return the buffer switched to."
   (interactive
    (list (read-buffer-to-switch "Switch to buffer: ") nil t))
   (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name)))
     (if (null force-same-window)
	(pop-to-buffer buffer display-buffer--same-window-action norecord)
       (cond
        ;; Don't call set-window-buffer if it's not needed since it
        ;; might signal an error (e.g. if the window is dedicated).
        ((eq buffer (window-buffer)))
        ((window-minibuffer-p)
	(error "Cannot switch buffers in minibuffer window"))
        ((eq (window-dedicated-p) t)
	(error "Cannot switch buffers in a dedicated window"))
        (t
	(let* ((entry (and (get-buffer-window buffer 0)
			   (assq buffer (window-prev-buffers))))
	       (start (and entry (nth 1 entry)))
	       (pos (and entry (nth 2 entry))))
	  (set-window-buffer nil buffer)
	  (when entry
	    ;; If BUFFER-OR-NAME (1) was shown in the selected window
	    ;; before and (2) is currently displayed in some other
	    ;; visible window, try to restore start and point of buffer
	    ;; in the selected window.
	    (set-window-start (selected-window) start t)
	    (set-window-point-1 nil pos)))))

       (unless norecord
	(select-window (selected-window)))
       (set-buffer buffer))))