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

["Drew Adams" <drew.adams@oracle.com>]

Caveat: I have not really been following this thread closely.

> > The trouble was that, when called on a dedicated window, it 
> > iconified the frame.
> 
> I don't follow: why do you think it's a trouble?  To me it's exactly
> what I want.  Is it that you prefer it deletes the frame rather than
> iconify it?

FWIW, iconifying is not what I would prefer.

`bury-buffer' is primarily about buffer order.  It's about getting the buffer
out of the way for `other-buffer'.

Only secondarily is it at all about display (almost as an afterthought):

"Also, if BUFFER-OR-NAME is nil or omitted,
remove the current buffer from the selected window if it is
displayed there."

It is impossible to "remove the current buffer from the selected window" if that
window is dedicated, so this secondary behavior naturally becomes a no-op in
that case.

If the window is dedicated, then I'd rather see one of these behaviors than I
would iconification of the buffer's frame:

a. Do nothing wrt the display.  See above: a no-op wrt display.
b. Delete the frame.

Iconifying can be annoying, depending on your OS.  I really don't see it as
appropriate for `bury-buffer'.  If code wants to iconify the frame it can always
do so explicitly.  Likewise for frame deletion, of course.

Perhaps the best approach is (a) above: have `bury-buffer' just bury the buffer
(i.e. affect the buffer order) and not have it do anything wrt the display in
this case.


Wrt `bs-cycle-next': I'm no expert on that (I don't use it), but wouldn't it
make sense for this kind of thing to _not_ affect the order of the default
buffer list, but rather to cycle its own copy/version of that list?

In that case, `bs' could decide how to handle buffers in dedicated windows for
its own purposes (cycling display), without altering the standard buffer order.
This would decouple `bs' cycling from `other-buffer' - would that be a good/bad
thing?  Dunno.

E.g., A priori, I see no reason why a buffer in a dedicated window should be
removed from the buffer list (by `bs-cycle-next' etc.).

The requirement seems to be only for `bs-cycle-next' to ignore that buffer or
skip over it or something.  But why should that action alter the standard buffer
list?

Again, I haven't followed this, and I know very little about `bs' etc.  If what
I say makes no sense, please ignore it.