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: martin rudalics <rudalics <at> gmx.at>
Cc: 8911 <at> debbugs.gnu.org
Subject: bug#8911: bs-cycle-next deletes window in some cases.
Date: Tue, 21 Jun 2011 17:02:25 +0200

On Tue, Jun 21, 2011 at 16:42, martin rudalics <rudalics <at> gmx.at> wrote:

> I think it's the correct way to handle the present case.  IIUC, all
> `bs-cycle-next' wants is to get the buffer out of the way in the
> buffer-list.  Is that assumption correct?

If you ask about the reason to call `bury-buffer' at that point, yes.
The reason to call `bs-cycle-next' is to rotate among the buffers in
the current window.

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

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
penalized; staying is better. Perhaps a message could be shown. Also,
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. Let's say
that I'm an extreme case of not wanting non-temporary windows unless I
create them myself explicitly.

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

> You're right.  My memory was wandering.

Well, not that I have refreshed it, it would be good if that wouldn't
iconify the frame ;-)

    Juanma

Previous Next

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