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

[Juanma Barranquero]

On Tue, Jun 21, 2011 at 16:42, martin rudalics <rudalics@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