[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: Mon, 27 Jun 2011 03:53:29 +0200

On Mon, Jun 27, 2011 at 03:30, Stefan Monnier <address@hidden> 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.


reply via email to

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