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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

As mentioned earlier, maybe the single-frame case is special, but I'd
really first like to know how you get into such a state.  For any other
case, M-x bury-buffer RET *should* iconify the current frame if it shows
a single dedicated window (with the caveat that Drew wants it to delete
the frame instead).

> If switch-to-buffer is changed not to fallback on pop-to-buffer, why
> shouldn't it be called from elisp?

Because 99% of the calls are wrong (they just want to display
a specific buffer and the author did not consider what should happen if
called in a minibuffer-only frame or in a dedicated window).

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

Yes, bs-cycle-next would be one of the very rare cases where calling
switch-to-buffer is the right thing to do.


        Stefan