GNU bug report logs - #8911
bs-cycle-next deletes window in some cases.

Previous Next

Full log

View this message in rfc822 format

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, 8911 <at> debbugs.gnu.org
Subject: bug#8911: bs-cycle-next deletes window in some cases.
Date: Tue, 21 Jun 2011 18:37:38 +0200

On Tue, Jun 21, 2011 at 18:28, Stefan Monnier <monnier <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.