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

[martin rudalics]

> 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