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

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

[Steve Yegge]

1) emacs -q  (with non-nil window-system)
2) find-file /usr/share/dict/words
   - any file longer than ~3x the frame height should serve to demonstrate
   - in remaining steps I'll call this file buffer BUF
3) (goto-char (/ (point-max) 2))
4) (new-frame)
5) (other-frame)  ; if necessary to put point in new frame
6) switch to buffer BUF
7) (goto-char (point-min))
8) switch to buffer *scratch* (or any other buffer)
9) switch to buffer BUF

Observe that point has returned to (/ (point-max) 2).

In Emacs 22, buffer point behaved as if it were frame-local:
at step 9, point would still be at (point-min).

This change may seem innocuous, but it can be quite frustrating and
mysterious if you have a multi-tty frame open at another site.
The buffer point behaves as if it's "stuck":  every time you switch
away from the buffer and return, the point has returned to its
sticky position.

The behavior exhibits in both multi-tty and single-tty flavors, but
is easier to trigger in a long-running multi-tty session distributed
over multiple sites (e.g. home and work).  It was serious enough to


In GNU Emacs 23.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.9)
 of 2009-04-14 on stevey.krc.corp.google.com
Windowing system distributor `The X.Org Foundation', version 11.0.60900000
configured using `configure  '--prefix=/home/stevey/no_crawl/emacs-cvs''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: C
  value of $LC_NUMERIC: C
  value of $LC_TIME: C
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> M-x s h e l l <return> C-x 
k <return> C-x b A <return> C-x k <return> C-x C-f 
C-a C-k / u s r / s h a r e / d i c t / w o r <tab> 
<return> C-x 2 C-x e M-> M-v M-v M-v C-r s t e C-a 
C-u C-r ^ s C-a C-x RET n e w - f r <tab> C-e C-a M-x 
n e w - f r <tab> <return> <switch-frame> <help-echo> 
<help-echo> <help-echo> C-x 2 C-x o C-x t M-< C-x b 
<return> C-x b w o <tab> <return> C-x o M-< C-x o C-v 
C-v C-v C-v C-v C-v C-v C-x o C-x 1 C-x b <return> 
C-x b w o <tab> <return> <switch-frame> M-x e <backspace> 
r e p o r t - e m a c s - b u g <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Note: file is write protected
kmacro-call-macro: No kbd macro has been defined
Mark set
Mark saved where search started [2 times]
Buffer is read-only: #<buffer words> [5 times]
indent-relative: Buffer is read-only: #<buffer words>
Mark set [2 times]

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

[martin rudalics]

 > This change may seem innocuous, but it can be quite frustrating and
 > mysterious if you have a multi-tty frame open at another site.
 > The buffer point behaves as if it's "stuck":  every time you switch
 > away from the buffer and return, the point has returned to its
 > sticky position.
 >
 > The behavior exhibits in both multi-tty and single-tty flavors, but
 > is easier to trigger in a long-running multi-tty session distributed
 > over multiple sites (e.g. home and work).  It was serious enough to

No substantial contribution wrt the behavior you observe but probably
installing pointback.el

http://stud4.tuwien.ac.at/~e0225855/pointback/pointback.html

would help you here (which is BTW yet another argument for preserving
window identities during sessions).

martin

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

[Lars Magne Ingebrigtsen]

Steve Yegge <stevey@google.com> writes:

> 1) emacs -q  (with non-nil window-system)
> 2) find-file /usr/share/dict/words
>    - any file longer than ~3x the frame height should serve to demonstrate
>    - in remaining steps I'll call this file buffer BUF
> 3) (goto-char (/ (point-max) 2))
> 4) (new-frame)
> 5) (other-frame)  ; if necessary to put point in new frame
> 6) switch to buffer BUF
> 7) (goto-char (point-min))
> 8) switch to buffer *scratch* (or any other buffer)
> 9) switch to buffer BUF
>
> Observe that point has returned to (/ (point-max) 2).

I can confirm that this behaviour is still present in Emacs 24.

And it seems like an unfortunate behaviour.  How difficult would it be
to stash window-point (I guess) on a per-frame basis?  Frame-local
variables are being phased out, but it seems like this would be nice to
have.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[martin rudalics]

 >> 1) emacs -q  (with non-nil window-system)
 >> 2) find-file /usr/share/dict/words
 >>    - any file longer than ~3x the frame height should serve to demonstrate
 >>    - in remaining steps I'll call this file buffer BUF
 >> 3) (goto-char (/ (point-max) 2))
 >> 4) (new-frame)
 >> 5) (other-frame)  ; if necessary to put point in new frame
 >> 6) switch to buffer BUF
 >> 7) (goto-char (point-min))
 >> 8) switch to buffer *scratch* (or any other buffer)
 >> 9) switch to buffer BUF
 >>
 >> Observe that point has returned to (/ (point-max) 2).
 >
 > I can confirm that this behaviour is still present in Emacs 24.
 >
 > And it seems like an unfortunate behaviour.  How difficult would it be
 > to stash window-point (I guess) on a per-frame basis?  Frame-local
 > variables are being phased out, but it seems like this would be nice to
 > have.

Even if you had such a feature it would not DTRT with multiple windows
showing the same buffer on the same frame.  But if, in step (9) above,
you do `previous-buffer' or `switch-to-prev-buffer', the window's point
should show up at `point-min'.  `switch-to-buffer' could, in principle,
retrieve that position by scanning `window-prev-buffers' of that window.

martin

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

[Lars Magne Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> Even if you had such a feature it would not DTRT with multiple windows
> showing the same buffer on the same frame.  But if, in step (9) above,
> you do `previous-buffer' or `switch-to-prev-buffer', the window's point
> should show up at `point-min'.  `switch-to-buffer' could, in principle,
> retrieve that position by scanning `window-prev-buffers' of that window.

I think that that sounds like a good idea.

I usually work with two frames, and this
return-the-point-to-where-it-is-in-the-other-frame behaviour has annoyed
me, too.  If you're doing two semi-related things in each frame,
"losing" the point you were at means a lot more jumping back and forth
in the buffer.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[Lars Magne Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> Even if you had such a feature it would not DTRT with multiple windows
> showing the same buffer on the same frame.  But if, in step (9) above,
> you do `previous-buffer' or `switch-to-prev-buffer', the window's point
> should show up at `point-min'.  `switch-to-buffer' could, in principle,
> retrieve that position by scanning `window-prev-buffers' of that window.

I think `switch-to-buffer' should do the same as `previous-buffer' here
-- it seems like the obvious solution.  Is there any reason not to?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[martin rudalics]

 >> Even if you had such a feature it would not DTRT with multiple windows
 >> showing the same buffer on the same frame.  But if, in step (9) above,
 >> you do `previous-buffer' or `switch-to-prev-buffer', the window's point
 >> should show up at `point-min'.  `switch-to-buffer' could, in principle,
 >> retrieve that position by scanning `window-prev-buffers' of that window.
 >
 > I think `switch-to-buffer' should do the same as `previous-buffer' here
 > -- it seems like the obvious solution.  Is there any reason not to?

We'd have to handle two issues:

(1) If a buffer is shown nowhere else and you `switch-to-buffer' to it,
     you probably want it to show it at the actual position of `point' -
     whatever that means for you.

(2) If the buffer is already shown on another frame with `point' visible
     it makes sense to `switch-to-buffer' at some position it earlier had
     on the present frame.

Whatever we did here, it would make `switch-to-buffer' behave
inconsistently.  I still think that the OP instead of

 > 8) switch to buffer *scratch* (or any other buffer)
 > 9) switch to buffer BUF

should switch to the previous buffer in 9).

martin

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

[Lars Magne Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> We'd have to handle two issues:
>
> (1) If a buffer is shown nowhere else and you `switch-to-buffer' to it,
>     you probably want it to show it at the actual position of `point' -
>     whatever that means for you.
>
> (2) If the buffer is already shown on another frame with `point' visible
>     it makes sense to `switch-to-buffer' at some position it earlier had
>     on the present frame.
>
> Whatever we did here, it would make `switch-to-buffer' behave
> inconsistently.

But it'd be the natural thing to do, I think.

> I still think that the OP instead of
>
>> 8) switch to buffer *scratch* (or any other buffer)
>> 9) switch to buffer BUF
>
> should switch to the previous buffer in 9).

People commonly use `C-x b' to switch buffers...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

[martin rudalics]

 >> We'd have to handle two issues:
 >>
 >> (1) If a buffer is shown nowhere else and you `switch-to-buffer' to it,
 >>     you probably want it to show it at the actual position of `point' -
 >>     whatever that means for you.
 >>
 >> (2) If the buffer is already shown on another frame with `point' visible
 >>     it makes sense to `switch-to-buffer' at some position it earlier had
 >>     on the present frame.
 >>
 >> 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?

 > People commonly use `C-x b' to switch buffers...

... and that's why I'm afraid of changing its semantics.  More so
because I never use C-x b.

We could make the behavior optional but I'd like to hear more comments
from other users first.  In any case this is a 24.2 project.

martin

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

[Steve Yegge]

[-- Attachment #1: Type: text/plain, Size: 5930 bytes --]

On Fri, Oct 7, 2011 at 10:00 AM, martin rudalics <rudalics@gmx.at> wrote:

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

[-- Attachment #2: Type: text/html, Size: 7577 bytes --]

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

[Eli Zaretskii]

> Date: Fri, 7 Oct 2011 14:09:14 -0700
> From: Steve Yegge <stevey@google.com>
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>, 4041@debbugs.gnu.org
> 
> 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.

+1

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

+1

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

[Drew Adams]

> > "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.
> +1
> > 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.
> +1

incf

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

[Leo]

On 2011-10-08 05:09 +0800, Steve Yegge wrote:
> 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! ;)

This is the problem the hack in
http://www.emacswiki.org/emacs/per-window-point.el tries to solve. It'd
be nice if emacs had that by default without advising any primitives.

Leo

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

[martin rudalics]

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

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

[Eli Zaretskii]

> Date: Sat, 08 Oct 2011 15:23:29 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>, 4041@debbugs.gnu.org
> 
> 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.

It doesn't do what I want because it doesn't accept a buffer
argument.  So I'm forced to try the previous buffers one by one, in
the LIFO order, until I find the one I have in mind.  And if I then
want to go back to one of those I visited on the way, I need either
use switch-to-next-buffer (if I happen to remember how far "forward"
that buffer is) or make the full circle, including *scratch* and
*Messages*, before I get there.

So I don't think switch-to-next/prev-buffer can be a convenient
solution to this problem.

What is necessary is a way to switch to a buffer by name and have the
window remember its previous window-point.  If the buffer was never
displayed in this window, "C-x b" should choose some value of
window-point that was used before and is not already displayed in some
other window.  (If there's a window for every possible value of
window-point for the buffer, i.e. the user opens yet another window
with the same buffer, just choose one of the values, e.g., the first
or the last.)  For the important use case of having 2 windows with the
same buffer, this strategy will do _exactly_ what the user wants.

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

Yes, but it works satisfactorily only if you switch between 2 buffers
in the same window.  Switch to a third, and you are screwed.

(And, btw, why aren't those 2 functions documented in the user
manual?)

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

[martin rudalics]

 > So I don't think switch-to-next/prev-buffer can be a convenient
 > solution to this problem.

Did you try it in practice?  With some convenient binding?  In my
experience, the buffer isn't too far away, usually.

 > What is necessary is a way to switch to a buffer by name and have the
 > window remember its previous window-point.  If the buffer was never
 > displayed in this window, "C-x b" should choose some value of
 > window-point that was used before and is not already displayed in some
 > other window.  (If there's a window for every possible value of
 > window-point for the buffer, i.e. the user opens yet another window
 > with the same buffer, just choose one of the values, e.g., the first
 > or the last.)  For the important use case of having 2 windows with the
 > same buffer, this strategy will do _exactly_ what the user wants.

Using the window-point from some other window will be utterly
disconcerting if you later want to display the buffer in _that_ other
window.  Recording window-points of deleted windows to implement the
"used before" approach might be expensive - these are markers into that
buffer.

 > Yes, but it works satisfactorily only if you switch between 2 buffers
 > in the same window.  Switch to a third, and you are screwed.

Try them.  I have bound `switch-to-prev-buffer' and
`switch-to-next-buffer' to M-left and M-right respectively and use them
all of the time.  Especially, because I usually tend to forget the names
of buffers I'm working on.  When you grow old enough you will eventually
even appreciate that.  Till then try the version of `switch-to-buffer' I
attached to the last mail and tell me whether you really need more.

 > (And, btw, why aren't those 2 functions documented in the user
 > manual?)

Because I haven't looked into that yet.

martin

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

[Eli Zaretskii]

> Date: Sat, 08 Oct 2011 17:00:42 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: stevey@google.com, larsi@gnus.org, 4041@debbugs.gnu.org
> 
>  > So I don't think switch-to-next/prev-buffer can be a convenient
>  > solution to this problem.
> 
> Did you try it in practice?

Of course, I did.  What makes you think I didn't?

> With some convenient binding?

How inconvenient can "M-x <up> RET" be?

> In my experience, the buffer isn't too far away, usually.

Maybe so, but I don't want to waste my time wading through buffers I
am not interested in.  If I need to see dispextern.h, I want to get
there, pronto.

>  > What is necessary is a way to switch to a buffer by name and have the
>  > window remember its previous window-point.  If the buffer was never
>  > displayed in this window, "C-x b" should choose some value of
>  > window-point that was used before and is not already displayed in some
>  > other window.  (If there's a window for every possible value of
>  > window-point for the buffer, i.e. the user opens yet another window
>  > with the same buffer, just choose one of the values, e.g., the first
>  > or the last.)  For the important use case of having 2 windows with the
>  > same buffer, this strategy will do _exactly_ what the user wants.
> 
> Using the window-point from some other window will be utterly
> disconcerting if you later want to display the buffer in _that_ other
> window.

Are you talking about the rare case in parentheses?  That's a marginal
use case.  Let's not destroy convenience in 90% of cases for the sake
of 10%.

> Recording window-points of deleted windows to implement the "used
> before" approach might be expensive - these are markers into that
> buffer.

So let's record only a few, up to a limit.  Again, having a lot of
such deleted windows is a rare case.

>  > Yes, but it works satisfactorily only if you switch between 2 buffers
>  > in the same window.  Switch to a third, and you are screwed.
> 
> Try them.

I did, before I responded.

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

[martin rudalics]

 > How inconvenient can "M-x <up> RET" be?

Very because it's not auto-repeatable.

 >> In my experience, the buffer isn't too far away, usually.
 >
 > Maybe so, but I don't want to waste my time wading through buffers I
 > am not interested in.  If I need to see dispextern.h, I want to get
 > there, pronto.

It's not about "If I need to see dispextern.h".  It's about "If I need
to see the dispextern.h where I left off in the same window."

 >>  > What is necessary is a way to switch to a buffer by name and have the
 >>  > window remember its previous window-point.  If the buffer was never
 >>  > displayed in this window, "C-x b" should choose some value of
 >>  > window-point that was used before and is not already displayed in some
 >>  > other window.  (If there's a window for every possible value of
 >>  > window-point for the buffer, i.e. the user opens yet another window
 >>  > with the same buffer, just choose one of the values, e.g., the first
 >>  > or the last.)  For the important use case of having 2 windows with the
 >>  > same buffer, this strategy will do _exactly_ what the user wants.
 >>
 >> Using the window-point from some other window will be utterly
 >> disconcerting if you later want to display the buffer in _that_ other
 >> window.
 >
 > Are you talking about the rare case in parentheses?

No.  I was talking about choosing "some value of window-point that was
used before" when switching to a buffer that was not shown in the
selected window yet.  If you next switch to the buffer in the window
where window-point was stolen from, you get the window-point from yet
another window.

 > That's a marginal
 > use case.  Let's not destroy convenience in 90% of cases for the sake
 > of 10%.
 >
 >> Recording window-points of deleted windows to implement the "used
 >> before" approach might be expensive - these are markers into that
 >> buffer.
 >
 > So let's record only a few, up to a limit.  Again, having a lot of
 > such deleted windows is a rare case.

So we record only a few but `switch-to-prev-buffer' isn't good enough to
get you to your buffer quickly.

 >>  > Yes, but it works satisfactorily only if you switch between 2 buffers
 >>  > in the same window.  Switch to a third, and you are screwed.
 >>
 >> Try them.
 >
 > I did, before I responded.

If you have auto-repeatable bindings it works very well.  I use them for
quite some time now and never had any complaints from my side so far.

martin

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

[Eli Zaretskii]

> Date: Sat, 08 Oct 2011 17:55:59 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: stevey@google.com, larsi@gnus.org, 4041@debbugs.gnu.org
> 
> [arguments]

To me, the current operation of "C-x b" is inconvenient, and
switch-to-prev/next-buffer is not a satisfactory solution.  But I'm
evidently unable to get the message across.  So I give up.  I lived
with this inconvenience for 20 years, I can live a bit longer.

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

[martin rudalics]

 > To me, the current operation of "C-x b" is inconvenient, and
 > switch-to-prev/next-buffer is not a satisfactory solution.  But I'm
 > evidently unable to get the message across.  So I give up.  I lived
 > with this inconvenience for 20 years, I can live a bit longer.

You could have at least told me why the version of `switch-to-buffer' I
attached to my first mail does not resolve most of that inconvenience.

martin

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

[Eli Zaretskii]

> Date: Sat, 08 Oct 2011 19:53:07 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: stevey@google.com, larsi@gnus.org, 4041@debbugs.gnu.org
> 
> You could have at least told me why the version of `switch-to-buffer' I
> attached to my first mail does not resolve most of that inconvenience.

I didn't try it, because you kept talking about the 2 other functions.
If it is supposed to take care of my gripes, why not commit it?

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

[martin rudalics]

 > I didn't try it, because you kept talking about the 2 other functions.
 > If it is supposed to take care of my gripes, why not commit it?

Because I hate reverting commits for reasons like "Emacs never did that".

martin

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

[Eli Zaretskii]

> Date: Sun, 09 Oct 2011 10:33:30 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: stevey@google.com, larsi@gnus.org, 4041@debbugs.gnu.org
> 
>  > I didn't try it, because you kept talking about the 2 other functions.

I tried it now.  It seems to do a good job, but it sometimes loses one
of the 2 places in one of the files I visited.  E.g., visit xdisp.c
and window.c, display each one in turn in 2 separate windows at 2
different places.  Then start switching buffers in both windows, and
after a few switches I can only see one place in window.c.

Still, this looks better than the current operation, so I recommend to
install it, perhaps as an optional behavior conditioned on some
customization.

Thanks.

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

[martin rudalics]

 > I tried it now.  It seems to do a good job, but it sometimes loses one
 > of the 2 places in one of the files I visited.  E.g., visit xdisp.c
 > and window.c, display each one in turn in 2 separate windows at 2
 > different places.  Then start switching buffers in both windows, and
 > after a few switches I can only see one place in window.c.

My crystal ball tells me that you did the following:

(1) Remove one of these buffers from the last window that shows it -
     `point' goes to its `window-point'.

(2) Show this buffer in the other window.

In this case the test

(let* ((entry (and (get-buffer-window buffer 0)
                    (assq buffer (window-prev-buffers))))

will fail and the buffer will be shown at the position of its `point'.
Try

(let* ((entry (and ; (get-buffer-window buffer 0)
                    (assq buffer (window-prev-buffers))))

and I'm sure the function will do what you want.

Unfortunately, omitting that conjunct might give surprising results when
you switch to a buffer that you haven't seen for quite some time, in a
window where this buffer was shown earlier.  In this case you probably
do want to show the buffer at the position of `point'.

martin

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

[Stefan Monnier]

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

FWIW that's what I implemented for doc-view's "pseudo point".
It was largely done because that was easier than trying to reproduce the
behavior of point.


        Stefan

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

[Steve Yegge]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

I don't know if anyone's expecting me to weigh in, as I've already used way
too many words to explain how I think it should work, and none of the
intervening discussion has given me a reason to reconsider that position.

But I'll add that defending the current behavior of switch-to-buffer is a
bit odd, since it doesn't do anything meaningful or useful as-is.

In particular, if you are switching to a buffer that is already showing in
another window, it currently takes you to to a location in that buffer that
can best be described as "arbitrary".  I was generously assuming that it was
some deterministic function of how the buffer is already being displayed in
other windows, but Martin claims that no, it just shows you "somewhere" in
the buffer, wherever that window-point happens to be.  It's certainly not
semantically meaningful to the contents of the buffer.

My proposal -- which people sound like they agree with, and Leo has even
implemented as an add-on -- takes the default behavior from arbitrary to not
only predictable but in fact useful.  The only way anyone would even notice
that you've changed something is if they were somehow relying on the
arbitrary default behavior, but as we've determined that it's not especially
predictable, I don't see how anyone could have been relying on it.  If we're
really worried about it, we can make a compatibility variable.

-steve

[-- Attachment #2: Type: text/html, Size: 1558 bytes --]

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

[Stefan Monnier]

> My proposal -- which people sound like they agree with, and Leo has even
> implemented as an add-on -- takes the default behavior from arbitrary to not
> only predictable but in fact useful.  The only way anyone would even notice
> that you've changed something is if they were somehow relying on the
> arbitrary default behavior, but as we've determined that it's not especially
> predictable, I don't see how anyone could have been relying on it.  If we're
> really worried about it, we can make a compatibility variable.

I think I generally agree it would be a good change.  But without an
actual patch, it's difficult to assess how reliable and backward
compatible we can make it.


        Stefan

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

[Steve Yegge]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

On Tue, Oct 11, 2011 at 6:19 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

>
> I think I generally agree it would be a good change.  But without an
> actual patch, it's difficult to assess how reliable and backward
> compatible we can make it.
>
>
Ah well, sadly I'm still on the hook for a couple other patches for you,
so it'd be unwise for me to volunteer for this one.

-steve

[-- Attachment #2: Type: text/html, Size: 728 bytes --]

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

 > I think I generally agree it would be a good change.  But without an
 > actual patch, it's difficult to assess how reliable and backward
 > compatible we can make it.

Attached find a diff with a new option
`switch-to-buffer-preserve-window-point'.

martin

[-- Attachment #2: stbpwp.diff --]
[-- Type: text/plain, Size: 2151 bytes --]

=== modified file 'lisp/window.el'
--- lisp/window.el	2011-10-10 17:52:03 +0000
+++ lisp/window.el	2011-10-12 09:23:47 +0000
@@ -4976,6 +4976,19 @@
 	    buffer))
     (other-buffer)))
 
+(defcustom switch-to-buffer-preserve-window-point nil
+  "If non-nil, `switch-to-buffer' tries to preserve `window-point'.
+If nil, `switch-to-buffer' displays the buffer at that buffer's
+`point'.  If non-nil, it tries to display the buffer at the last
+position of `window-point' in the window used for display.
+
+If the window used for display is either new, or the buffer
+already appears in it, or the buffer never appeared in that
+window, this variable has no impact."
+  :type 'boolean
+  :group 'windows
+  :version "24.1")
+
 (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
@@ -5001,7 +5014,7 @@
 
 Return the buffer switched to."
   (interactive
-   (list (read-buffer-to-switch "Switch to buffer: ") nil nil))
+   (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)
@@ -5013,7 +5026,19 @@
 	(error "Cannot switch buffers in minibuffer window"))
        ((eq (window-dedicated-p) t)
 	(error "Cannot switch buffers in a dedicated window"))
-       (t (set-window-buffer nil buffer)))
+       (t
+	(let* ((entry (and switch-to-buffer-preserve-window-point
+			   (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)))

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

[Stefan Monnier]

> Attached find a diff with a new option
> `switch-to-buffer-preserve-window-point'.

That looks pretty good.  I'd be willing to try and turn it on by default
in something like Emacs-25 or maybe even 24.2.


        Stefan

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

[Stefan Monnier]

>> Attached find a diff with a new option `switch-to-buffer-preserve-window-point'.
> That looks pretty good.  I'd be willing to try and turn it on by default
> in something like Emacs-25 or maybe even 24.2.

One thing bothers me, tho: why not do it in set-window-buffer?


        Stefan

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

[martin rudalics]

 > One thing bothers me, tho: why not do it in set-window-buffer?

No particular reason but that an Elisp function is easier to experiment
with than a C function.

martin

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

 > That looks pretty good.  I'd be willing to try and turn it on by default
 > in something like Emacs-25 or maybe even 24.2.

I completely forgot about this.  Any objections to install the attached
version for 24.3?

 > One thing bothers me, tho: why not do it in set-window-buffer?

I'm still not sure whether this would be safe in all cases.  I wouldn't
even do that for plain `display-buffer'.  The current patch addresses
all requests raised in the current thread.  If there's real need to
provide this option for other functions as well, we can still do that.

martin

[-- Attachment #2: switch-to-buffer-preserve-window-point.diff --]
[-- Type: text/plain, Size: 3025 bytes --]

=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2012-10-04 12:56:14 +0000
+++ lisp/ChangeLog	2012-10-05 09:40:16 +0000
@@ -1,3 +1,10 @@
+2012-10-05  Martin Rudalics  <rudalics@gmx.at>
+
+	* window.el (switch-to-buffer-preserve-window-point): New
+	option.
+	(switch-to-buffer): Optionally preserve window point if buffer
+	appeared earlier in the selected window (Bug#4041).
+
 2012-10-04  Martin Rudalics  <rudalics@gmx.at>
 
 	* emacs-lisp/edebug.el (edebug-pop-to-buffer): Select window

=== modified file 'lisp/window.el'
--- lisp/window.el	2012-09-30 10:44:43 +0000
+++ lisp/window.el	2012-10-05 09:47:10 +0000
@@ -5812,6 +5812,25 @@
 	    buffer))
     (other-buffer)))
 
+(defcustom switch-to-buffer-preserve-window-point nil
+  "If non-nil, `switch-to-buffer' tries to preserve `window-point'.
+If this is nil, `switch-to-buffer' displays the buffer at that
+buffer's `point'.  If this is `already-displayed', it tries to
+display the buffer at its last position in the selected window
+provided the buffer is curently displayed in some other window on
+a visible or iconified frame.  If this is t, it always tries to
+display the buffer at its last position in the selected window.
+
+If the window used for display is either new, or the buffer
+already appears in it, or the buffer never appeared in that
+window, the setting of this variable has no impact."
+  :type '(choice
+	  (const :tag "Never" nil)
+	  (const :tag "If already displayed elsewhere" already-displayed)
+	  (const :tag "Always" t))
+  :group 'windows
+  :version "24.3")
+
 (defun switch-to-buffer (buffer-or-name &optional norecord force-same-window)
   "Switch to buffer BUFFER-OR-NAME in the selected window.
 If the selected window cannot display the specified
@@ -5837,6 +5856,10 @@
 must be displayed in the selected window; if that is impossible,
 signal an error rather than calling `pop-to-buffer'.
 
+The option `switch-to-buffer-preserve-window-point' can be used
+to make the buffer appear at its last position in the selected
+window.
+
 Return the buffer switched to."
   (interactive
    (list (read-buffer-to-switch "Switch to buffer: ") nil 'force-same-window))
@@ -5853,7 +5876,21 @@
       (if force-same-window
           (user-error "Cannot switch buffers in a dedicated window")
         (pop-to-buffer buffer norecord)))
-     (t (set-window-buffer nil buffer)))
+     (t
+      (let* ((entry (assq buffer (window-prev-buffers)))
+	     (displayed (and (eq switch-to-buffer-preserve-window-point
+				 'already-displayed)
+			     (get-buffer-window buffer 0)))
+	     (start (and entry (nth 1 entry)))
+	     (pos (and entry (nth 2 entry))))
+	(set-window-buffer nil buffer)
+	(when (and entry
+		   (or (eq switch-to-buffer-preserve-window-point t)
+		       displayed))
+	  ;; Try to restore start and point of buffer in the selected
+	  ;; window (Bug#4041).
+	  (set-window-start (selected-window) start t)
+	  (set-window-point nil pos)))))
 
     (unless norecord
       (select-window (selected-window)))

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

[martin rudalics]

>  > That looks pretty good.  I'd be willing to try and turn it on by default
>  > in something like Emacs-25 or maybe even 24.2.
> 
> I completely forgot about this.  Any objections to install the attached
> version for 24.3?

Installed.  Bug closed.

martin

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

[martin rudalics]

 > In particular, if you are switching to a buffer that is already showing in
 > another window, it currently takes you to to a location in that buffer that
 > can best be described as "arbitrary".  I was generously assuming that it was
 > some deterministic function of how the buffer is already being displayed in
 > other windows, but Martin claims that no, it just shows you "somewhere" in
 > the buffer, wherever that window-point happens to be.  It's certainly not
 > semantically meaningful to the contents of the buffer.

I never claimed that

   it just shows you "somewhere" in the buffer, wherever that
   window-point happens to be

Such a sentence doesn't make sense.  To clarify: If `switch-to-buffer'
shows a buffer in a new window or in a window that showed another buffer
before, it takes you to the position of `point' of the buffer you switch
to.  This is not an arbitrary position.

 > My proposal -- which people sound like they agree with, and Leo has even
 > implemented as an add-on -- takes the default behavior from arbitrary to not
 > only predictable but in fact useful.  The only way anyone would even notice
 > that you've changed something is if they were somehow relying on the
 > arbitrary default behavior, but as we've determined that it's not especially
 > predictable, I don't see how anyone could have been relying on it.  If we're
 > really worried about it, we can make a compatibility variable.

If you can specify a behavior that is predictable I'll be all ears.

Meanwhile I invite you to test the function I attached in my answer to
your earlier post, maybe together with the change I posted later in a
response to Eli, and tell me why the one or the other does not do what
you proposed.

martin