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

Previous Next

Full log

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

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

On Mon, Jun 27, 2011 at 03:30, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> I'm not sure about the third (isn't it also fixed by passing a non-nil
> arg to bury-buffer?)

Well, yes, but that means "fixing" it everywhere; I mean:

emacs -Q
M-: (set-window-dedicated-p (selected-window) t) <RET>
M-x bury-buffer <RET>

and the frame is iconified. It shouldn't.

> but for the second the right fix is to remove the
> "fallback on pop-to-buffer" from switch-to-buffer.  Of course, that will
> (re)introduce new bugs which we could/should "fix" by marking
> switch-to-buffer (and find-file and maybe a few more) as "don't call
> from Elisp".

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.

    Juanma

Previous Next

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