[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Juanma Barranquero
Subject: bug#8911: bs-cycle-next deletes window in some cases.
Date: Wed, 29 Jun 2011 05:57:23 +0200

On Wed, Jun 29, 2011 at 05:27, Stefan Monnier <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]