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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juanma Barranquero <lekktu <at> gmail.com>
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 12:28:06 -0400

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

Previous Next

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