GNU bug report logs - #8911
bs-cycle-next deletes window in some cases.

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 8911 <at> debbugs.gnu.org
Subject: bug#8911: bs-cycle-next deletes window in some cases.
Date: Tue, 21 Jun 2011 15:37:52 +0200

> With current trunk.
>
>   emacs -Q -l bs
>   C-x 2
>   M-x bs-cycle-next <RET>
>
> and the bottom window is deleted.

IIUC this happens because of this code

	(unless (window-dedicated-p (selected-window))
	  ;; We don't want the frame iconified if the only window in the frame
	  ;; happens to be dedicated; let's get the error from switch-to-buffer
	  (bury-buffer))
	(switch-to-buffer next)

in `bs-cycle-next' and `bury-buffer' can now delete a window showing the
buffer provided this buffer was the first to appear in a window.

`bs-cycle-next' is probably not to blame because it just wants to make
sure that the buffer is not chosen again soon for displaying it.  So we
have a number of ways to restore the old behavior, namely

- have `bs-cycle-next' call `unrecord-buffer' instead of `bury-buffer',

- have `bury-buffer' only delete dedicated windows as before,

- give `bury-buffer' an extra argument which allows (or forbids) to
  delete the selected window (or corresponding frame),

- make sure that `bury-buffer' deletes only automatically created
  windows (much like the recent option `frame-auto-delete').

Personally, I have no preference since I never understood the
"additional" semantics of `bury-buffer'.  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?

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.