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

[martin rudalics]

>> - have `bs-cycle-next' call `unrecord-buffer' instead of `bury-buffer',
>
> That seems to work, yes.

I think it's the correct way to handle the present case.  IIUC, all
`bs-cycle-next' wants is to get the buffer out of the way in the
buffer-list.  Is that assumption correct?

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

I stand corrected.  But then the buffer shown in the dedicated window
kept its position in the buffer list.  Isn't that a bug?

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

But it requires for each caller to guess the right approach :-(

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

Those infamous windows popped up by `display-buffer'.  I'm afraid that a
user of `bs-cycle-next' will hardly remember why the window was created
in the first place.

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

You're right.  My memory was wandering.

martin