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

[Juanma Barranquero <lekktu@gmail.com>]

On Mon, Jun 27, 2011 at 03:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I'm not sure about the third (isn't it also fixed by passing a non-nil
> arg to bury-buffer?)

Well, yes, but that means "fixing" it everywhere; I mean:

emacs -Q
M-: (set-window-dedicated-p (selected-window) t) <RET>
M-x bury-buffer <RET>

and the frame is iconified. It shouldn't.

> but for the second the right fix is to remove the
> "fallback on pop-to-buffer" from switch-to-buffer.  Of course, that will
> (re)introduce new bugs which we could/should "fix" by marking
> switch-to-buffer (and find-file and maybe a few more) as "don't call
> from Elisp".

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.

    Juanma