bug#8911: bs-cycle-next deletes window in some cases.

[Juanma Barranquero <lekktu@gmail.com>]

On Mon, Jun 27, 2011 at 14:46, martin rudalics <rudalics@gmx.at> wrote:

> If the user wants to change the default behavior, yes.

Ah. Current documentation for display-buffer-alist is less than clear to me.

> I'm not sure whether we want to do that.

Well, I'm not sure whether *we* want, either, but I'm definitely sure
I want (locally, I mean).

> If so, there are two ways.
> Either, in `bs-cycle-next' write something like:
>
>  (if (and (window-dedicated-p) (not (eq (window-buffer) next)))
>      (error "Selected window is dedicated to its buffer")
>    (display-buffer-same-window next))
>
> which gives the user no choice wrt what to do when the selected window
> is dedicated

I supose this is a no-no.

>  or write
>
> (defun reuse-same-window-unless-dedicated (buffer &rest args)
>  "..."
>  (if (and (window-dedicated-p) (not (eq (window-buffer) next)))
>      (error "Selected window is dedicated to its buffer")
>    (display-buffer-same-window buffer)))
>
> (display-buffer
>  next '((fun-with-args reuse-same-window-unless-dedicated)) 'bs-cycle-next)
>
> and allow the user to specify her own deviant behavior when the selected
> window is dedicated.

I don't follow you. reuse-same-window-unless-dedicated is throwing an
error unconditionally. How would the user specifiy her own behavior?

    Juanma