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

[Juanma Barranquero]

On Tue, Jun 21, 2011 at 15:37, martin rudalics <rudalics@gmx.at> wrote:

> `bs-cycle-next' is probably not to blame because it just wants to make
> sure that the buffer is not chosen again soon for displaying it.  So we
> have a number of ways to restore the old behavior, namely
>
> - have `bs-cycle-next' call `unrecord-buffer' instead of `bury-buffer',

That seems to work, yes.

> - have `bury-buffer' only delete dedicated windows as before,

I don't follow you. Before that change, bury-buffer was not called
only on dedicated windows. The trouble was that, when called on a
dedicated window, it iconified the frame.

> - give `bury-buffer' an extra argument which allows (or forbids) to
>  delete the selected window (or corresponding frame),

Perhaps this is the best long term answer.

> - make sure that `bury-buffer' deletes only automatically created
>  windows (much like the recent option `frame-auto-delete').

What's an "automatically created window"?

> Earlier versions of this used
> to iconify frames which some people on this list disliked severely so I
> removed it.  So far no one missed this issue, but maybe I shall restore
> it as well?

Again, I don't follow you. This:

(progn
  (set-window-dedicated-p (selected-window) t)
  (bury-buffer))

still iconifies the frame.

    Juanma