[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: martin rudalics
Subject: bug#8911: bs-cycle-next deletes window in some cases.
Date: Mon, 27 Jun 2011 09:00:56 +0200
User-agent: Thunderbird (Windows/20090302)

> 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)


reply via email to

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