Subject: Re: bug#8911: bs-cycle-next deletes window in some cases.

From: martin rudalics <[email-masked]>
Date: Mon, 27 Jun 2011 09:00:56 +0200

> If switch-to-buffer is changed not to fallback on pop-to-buffer, why
 > shouldn't it be called from elisp? In the case of bs-cycle-next:
 >
 >         (unless (window-dedicated-p (selected-window))
 >           ;; We don't want the frame iconified if the only window in the frame
 >           ;; happens to be dedicated
 >           (bury-buffer (current-buffer)))
 >         (switch-to-buffer next)
 >
 > the current switch-to-buffer causes the unwanted-splitting behavior.
 > Changing it to pop-to-buffer-same-window, as its docstring suggests,
 > would still cause the same problem.

`switch-to-buffer' has a specific window show a specific buffer.  The
user cannot change that via options.

`pop-to-buffer-same-window' tries to show a specific buffer in a
specific window.  But the user can change that via options.  In
particular, the user can decide to override the splitting behavior,
dedicatedness of windows, ...  All `bs-cycle-next' has to do is call
it via

(pop-to-buffer-same-window next nil 'bs-cycle-next)

martin