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

["Drew Adams" <drew.adams@oracle.com>]

>  > Let me also be clear that it is not about hook vs option.  
>  > It would be fine with me if we had a user option for this
>  > instead of a hook, as long as it let you do just as much.
> 
> Since I hardly ever bury a buffer please tell me when and how you want
> to set up things and what precisely you want that option to 
> do.

I hardly ever (never?) bury a buffer explicitly either.  But as Juanma pointed
out, we all use (vanilla) Lisp code that calls `bury-buffer'.

Anyway, I don't have a precise idea wrt such an option.

The general idea is to give users some (easy) way to specify a particular
behavior to invoke after `bury-buffer' does its thing of changing the buffer
order.  IOW, that extra behavior would be invoked/initiated by `bury-buffer'.

This is not (for me) about any old change in the buffer order.  It is only about
complementing the buffer order-changing behavior of `bury-buffer' by adding some
user-specified (display) behavior.

> We now have an option called `frame-auto-delete' which
> might be expanded to do something in this sense.

I don't know anything about that.

This is not fundamentally about frame deletion.  Deleting the frame in this
situation would be only one possible user preference.  We should not focus on it
in particular, I think.

>  > E.g., a function to be invoked after the buffer order is changed.
> 
> `buffer-list-update-hook' is run when the "buffer order" 
> changes.  Note that there were "f + 1" buffer orders in
> Emacs 23 where "f" is the number of live frames and there
> are "f + w + 1" buffer orders in Emacs 24 where "w" is
> the number of live windows.

Again, I'm no expert on this, in any Emacs version.

This is about `bury-buffer' (only), and therefore about its particular
reordering of the buffer list.  After it reorders the list to bury the buffer, a
given user (e.g. Stefan, Drew) might want `bury-buffer' to do something about
the window or frame that displays that buried buffer.

That's the idea - let users specify that display behavior.  But I suppose that
any behavior whatever could be handled here, not necessarily something to do
with displaying that particular buffer window/frame.  Put differently,
specifying what to do in addition to changing the buffer order could involve
other things besides (in addition to or instead of) display.

>  > Function `ignore' would take care of the do-nothing case.
>  > The function would need to accept the buffer as its (first)
>  > argument.
> 
> `buffer-list-update-hook' doesn't have a buffer as argument.  We could
> change that.  But this would not necessarily tell you enough about the
> frame that should be deleted or iconified.

I don't think (without really knowing anything about that hook) that that hook
would be appropriate here.  This is only about `bury-buffer' and _its_
particular reordering of the buffer list to bury the buffer.

But you're no doubt right that knowing only the buffer would not be enough.
Probably the function (option value or new-hook entry) should take the buffer's
window as argument also.  `bury-buffer' knows what that window is.

The idea is to let `bury-buffer' do something about the buffer's window/frame,
if the user wants that.  That's all.  I'd guess that knowing the buffer and the
window would be enough.  The frame can be gotten from the window.

So pretty much anything the user would like to do in this context should be
possible by specifying a function that accepts the buffer and window as args.
Unless I'm missing something.

Ideally, the user should be able to specify a function that accepts those two
args and does anything it wants.  It could test other things in the current
context, besides that buffer and window, and do something appropriate wrt the
buffer's display.  It could do something different depending on whether this is
a special-display situation, or depending on what the buffer name is, or...

I'm not trying to specify the exact implementation.  No doubt both of you have
good ideas about that.  My only point is that we should try to:

1. Decouple burying the buffer (changing the buffer order) from doing something
about the buffer's display.

2. Let users optionally specify something to do wrt the buffer's display.

3. Make sure that #2 is open-ended, not limited to just choosing between
deleting the buffer's frame and iconifying it.

A question is whether this is all about just the dedicated-window case or not.
We've kind of been talking as if it is only about that case.  And that sounds
right to me.

But we might also want to think about whether such a feature (user specification
of what to do about display, after reordering the buffer list)
would/should/could also be applicable to other, non dedicated-window, cases for
`bury-buffer'.  Dunno.