GNU bug report logs -
#8911
bs-cycle-next deletes window in some cases.
Previous Next
Full log
Message #116 received at 8911 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jun 29, 2011 at 05:27, Stefan Monnier <monnier <at> 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
This bug report was last modified 13 years and 324 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.