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

[martin rudalics <rudalics@gmx.at>]

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