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

[Drew Adams]

> > As I also said earlier, to me (and per the doc string and the
> > function's past behavior) `bury-buffer' is not about display.  (That
> > is, it is only secondarily about display, and only in the one
> > particular case quoted above.)
> 
> There are two ways to call bury-buffer, which correspond to two fairly
> different behaviors.  One is with a non-nil argument, where it only
> touches the order in the buffer-list.  This one is uncontroversial and
> doesn't matter much to me.

Right.  Glad that at least in this case you're OK with not doing anything wrt
display.

> The other is when the argument is nil, in which case it is
> *specifically* meant to make the buffer disappear

I'm sure I won't be able to convince you, but that is not what the doc string
indicates.  It speaks only about removing the current buffer _from the selected
window_ (if displayed there).

To you maybe that suggests something about "disappearing" in the case of a
dedicated window.

To me it suggests nothing of the kind.  To me it suggests on the contrary that
this is not at all about that particular case, but is instead _ONLY_ about the
case where the buffer _CAN_ be removed from the window.  

To me, that sentence, which has been around since Day One, covers only the
special case that does _not_ include dedicated windows, since the current buffer
cannot be removed from such a window.

Dedicated windows have also been around a long time, yet the `bury-buffer' doc
never said anything about doing anything to a dedicated window or its frame.

Never UNTIL, that is, Emacs 23, when you (Emacs Dev) changed it - in the manual.
You added this: "But if the selected window is dedicated to its buffer, it
deletes that window if there are other windows left on its frame.  Otherwise, if
the selected window is the only window on its frame, it iconifies that frame."

That was never the behavior or the interpretation (doc) before that.  AFAIK,
before Emacs 23 `bury-buffer' never did anything about the window in the
dedicated case.  It certainly never made the buffer "disappear" in any way for
that case.

Instead, it raised the error "Cannot switch buffers in a dedicated window",
which to me sounds right.  No doubt you consider that previous behavior a bug,
but I expect it was by design, and I think it was not a bad choice.

> (additionally to changing the buffer-list order).  This case is
> very much about display, not just secondarily so.

Not for the dedicated case - not until Emacs 23, that is.  That behavior was
grafted on, and IMO it was a mistake.

> > The reason is primarily the annoyance that iconifying can 
> > produce - on Windows it is kind of animated, essentially
> > sweeping across the display down to the task bar.  With
> > frame deletion it just disappears instantly - poof.
> 
> Then we could add an option so that bury-buffer uses delete-frame
> instead of iconify-frame.

Or `ignore' instead of `iconify-frame'...

But why not instead do as I suggested earlier:

1. Return to the pre-23 behavior, so that `bury-buffer' is once again not about
display. 

2. Add a `bury-buffer-hook', to let people tack on any behavior they like,
whether related to display or not.

You might tack on `iconify-frame'.  I might (or might not) tack on
`delete-frame'.  Joe Lambda might tack on a logging function to record buffer
activity or something.

I agree that it will not be uncommon to want to associate some display behavior
with `bury-buffer'.  I don't think the right idea is to try to decide on one
display behavior that fits all.  And I would opt for a hook (keeping
`bury-buffer' display-free) rather than an option whose default value is some
display behavior (e.g. `iconify-frame').

> But doing nothing is not an option since the caller
> specifically asked to undisplay the buffer.

Not until you changed the meaning to that.  A caller of `bury-buffer' wants to
change the buffer order.  Why mix in additional behavior, so that a caller must
now "want" to do a particular mix of things that don't necessarily go together?

FWIW.