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

[Stefan Monnier]

>> I stand corrected.  But then the buffer shown in the dedicated window
>> kept its position in the buffer list.  Isn't that a bug?

Yes, tho it's probably minor.

> If the window is dedicated, and the user invokes bs-cycle-next
> (usually, by having it bound to a key, and not realizing that the
> window is dedicated), that's user error, but the user should not be

Not if the window is softly-dedicated (in which case the window should
be un-dedicated).

> no new window should be created. For example, I find the current
> behavior

>   emacs -Q -l bs
>   C-h N
>   C-h C-c
>   M-: (set-window-dedicated-p (selected-window) t) <RET>
>   M-x bs-cycle-next <RET>

> of splitting the window extremely unuseful and unhelpful.

But that's the semantics of (set-window-dedicated-p (selected-window) t).
If you don't like it, then you should use
(set-window-dedicated-p (selected-window) 'soft) instead.

>> Those infamous windows popped up by `display-buffer'.  I'm afraid that a
>> user of `bs-cycle-next' will hardly remember why the window was created
>> in the first place.
> Definitely.

That's the whole idea behind soft-dedication.


        Stefan