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

Previous Next

Full log

Message #92 received at 8911 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 8911 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#8911: bs-cycle-next deletes window in some cases.
Date: Mon, 27 Jun 2011 09:00:56 +0200

> If switch-to-buffer is changed not to fallback on pop-to-buffer, why
> shouldn't it be called from elisp? In the case of bs-cycle-next:
>
>         (unless (window-dedicated-p (selected-window))
>           ;; We don't want the frame iconified if the only window in the frame
>           ;; happens to be dedicated
>           (bury-buffer (current-buffer)))
>         (switch-to-buffer next)
>
> the current switch-to-buffer causes the unwanted-splitting behavior.
> Changing it to pop-to-buffer-same-window, as its docstring suggests,
> would still cause the same problem.

`switch-to-buffer' has a specific window show a specific buffer.  The
user cannot change that via options.

`pop-to-buffer-same-window' tries to show a specific buffer in a
specific window.  But the user can change that via options.  In
particular, the user can decide to override the splitting behavior,
dedicatedness of windows, ...  All `bs-cycle-next' has to do is call
it via

(pop-to-buffer-same-window next nil 'bs-cycle-next)

martin

Previous Next

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