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

[Juanma Barranquero]

On Tue, Jun 21, 2011 at 18:28, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

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

Yes, I'm talking of strong dedication.

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

The semantics of strong dedication is not entirely clear to me, but
I'd say it is more about what happens to the window/buffer
correspondence, that what happens in other windows or to other
buffers. In other words, if I make a window strongly dedicated I'm not
saying I what I do want about other buffers or other windows, I'm only
saying "I don't want other buffers in this window".

I agree cases are not always clear cut, and I suppose that in other
situations I would find the behavior that you describe quite logical.
Not so for bs-cycle-next, whose purpose is to cycle buffers in the
current window (I should know, I was the one to propose these commands
to Olaf Sylvester quite a few years ago, and judging by the ChangeLogs
I'm the main user of bs.el among the Emacs developers ;-)

    Juanma