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

[Juanma Barranquero]

On Wed, Jun 29, 2011 at 05:27, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

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

As I explained, I have strongly-dedicated windows, and every now and
then I end doing C-x 1 inside one of them. As it isn't usually what I
wanted, I immediately do <f10> (which I have bound to bs-cycle-next).
But, leaving aside my own use case, yeah, for the single frame use
case, iconifying it is hardly going to be useful for anyone, I think.

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

I don't even agree with your example, because I certainly wouldn't
want my frames iconified (and, in any case, I'd use M-x iconify-frame
<RET> for that). But explicit interactive calls of bury-buffer are not
what I complain about; I don't mind these, because I just don't ever
use them. My problem happens when bury-buffer is called from some
elisp code that does a poor job of reading my mind: no, mr. program, I
don't really want my frames iconified, thank you very much.
bs-cycle-next is just the most prominent example of that bad behavior,
because I use it a lot.

So, I don't mind which is the default, as long as there's a way to
customize it (with Martin's new window machinery, not redefining
functions) to my tastes.

    Juanma