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

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

[Juanma Barranquero]

With current trunk.

  emacs -Q -l bs
  C-x 2
  M-x bs-cycle-next <RET>

and the bottom window is deleted.

    Juanma

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

[martin rudalics]

 > With current trunk.
 >
 >   emacs -Q -l bs
 >   C-x 2
 >   M-x bs-cycle-next <RET>
 >
 > and the bottom window is deleted.

IIUC this happens because of this code

	(unless (window-dedicated-p (selected-window))
	  ;; We don't want the frame iconified if the only window in the frame
	  ;; happens to be dedicated; let's get the error from switch-to-buffer
	  (bury-buffer))
	(switch-to-buffer next)

in `bs-cycle-next' and `bury-buffer' can now delete a window showing the
buffer provided this buffer was the first to appear in a window.

`bs-cycle-next' is probably not to blame because it just wants to make
sure that the buffer is not chosen again soon for displaying it.  So we
have a number of ways to restore the old behavior, namely

- have `bs-cycle-next' call `unrecord-buffer' instead of `bury-buffer',

- have `bury-buffer' only delete dedicated windows as before,

- give `bury-buffer' an extra argument which allows (or forbids) to
   delete the selected window (or corresponding frame),

- make sure that `bury-buffer' deletes only automatically created
   windows (much like the recent option `frame-auto-delete').

Personally, I have no preference since I never understood the
"additional" semantics of `bury-buffer'.  Earlier versions of this used
to iconify frames which some people on this list disliked severely so I
removed it.  So far no one missed this issue, but maybe I shall restore
it as well?

martin

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

[Juanma Barranquero]

On Tue, Jun 21, 2011 at 15:37, martin rudalics <rudalics@gmx.at> wrote:

> `bs-cycle-next' is probably not to blame because it just wants to make
> sure that the buffer is not chosen again soon for displaying it.  So we
> have a number of ways to restore the old behavior, namely
>
> - have `bs-cycle-next' call `unrecord-buffer' instead of `bury-buffer',

That seems to work, yes.

> - have `bury-buffer' only delete dedicated windows as before,

I don't follow you. Before that change, bury-buffer was not called
only on dedicated windows. The trouble was that, when called on a
dedicated window, it iconified the frame.

> - give `bury-buffer' an extra argument which allows (or forbids) to
>  delete the selected window (or corresponding frame),

Perhaps this is the best long term answer.

> - make sure that `bury-buffer' deletes only automatically created
>  windows (much like the recent option `frame-auto-delete').

What's an "automatically created window"?

> Earlier versions of this used
> to iconify frames which some people on this list disliked severely so I
> removed it.  So far no one missed this issue, but maybe I shall restore
> it as well?

Again, I don't follow you. This:

(progn
  (set-window-dedicated-p (selected-window) t)
  (bury-buffer))

still iconifies the frame.

    Juanma

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

[martin rudalics]

 >> - have `bs-cycle-next' call `unrecord-buffer' instead of `bury-buffer',
 >
 > That seems to work, yes.

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?

 >> - have `bury-buffer' only delete dedicated windows as before,
 >
 > I don't follow you. Before that change, bury-buffer was not called
 > only on dedicated windows. The trouble was that, when called on a
 > dedicated window, it iconified the frame.

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

 >> - give `bury-buffer' an extra argument which allows (or forbids) to
 >>  delete the selected window (or corresponding frame),
 >
 > Perhaps this is the best long term answer.

But it requires for each caller to guess the right approach :-(

 >> - make sure that `bury-buffer' deletes only automatically created
 >>  windows (much like the recent option `frame-auto-delete').
 >
 > What's an "automatically created window"?

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.

 >> Earlier versions of this used
 >> to iconify frames which some people on this list disliked severely so I
 >> removed it.  So far no one missed this issue, but maybe I shall restore
 >> it as well?
 >
 > Again, I don't follow you. This:
 >
 > (progn
 >   (set-window-dedicated-p (selected-window) t)
 >   (bury-buffer))
 >
 > still iconifies the frame.

You're right.  My memory was wandering.

martin

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

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

[martin rudalics]

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

Because it does (switch-to-buffer next) in `bs-cycle-next'?  Well, what
else should it do?  Undedicate the window?  That is a tricky case.

martin

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

[Juanma Barranquero]

On Tue, Jun 21, 2011 at 18:12, martin rudalics <rudalics@gmx.at> wrote:

> Because it does (switch-to-buffer next) in `bs-cycle-next'?  Well, what
> else should it do?  Undedicate the window?  That is a tricky case.

Fail, i.e., do nothing (except displaying a message).

BTW, I'm not saying that switch-to-buffer should do nothing, I'm
saying that I expect bs-cycle-next to do nothing in such case. The
current behavior is not "cycling". But this is unrelated to your
changes, it already happens in 23.X. I'm more interested in fixing the
original problem.

    Juanma

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

[Stefan Monnier]

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

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

[Juanma Barranquero]

On Tue, Jun 21, 2011 at 18:28, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

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

Yes, I'm talking of strong dedication.

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

The semantics of strong dedication is not entirely clear to me, but
I'd say it is more about what happens to the window/buffer
correspondence, that what happens in other windows or to other
buffers. In other words, if I make a window strongly dedicated I'm not
saying I what I do want about other buffers or other windows, I'm only
saying "I don't want other buffers in this window".

I agree cases are not always clear cut, and I suppose that in other
situations I would find the behavior that you describe quite logical.
Not so for bs-cycle-next, whose purpose is to cycle buffers in the
current window (I should know, I was the one to propose these commands
to Olaf Sylvester quite a few years ago, and judging by the ChangeLogs
I'm the main user of bs.el among the Emacs developers ;-)

    Juanma

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

[Stefan Monnier]

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

Sorry, you're right.  The right thing to do here is to signal an error,
not to split the window.


        Stefan

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

[Juanma Barranquero]

On Wed, Jun 22, 2011 at 04:14, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Sorry, you're right.  The right thing to do here is to signal an error,
> not to split the window.

That's what it did until 22.3; it displayed "Cannot switch buffers in
a dedicated window".

    Juanma

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

[Stefan Monnier]

>> Sorry, you're right.  The right thing to do here is to signal an error,
>> not to split the window.
> That's what it did until 22.3; it displayed "Cannot switch buffers in
> a dedicated window".

I know, I'm to blame for the change in Emacs-23, where I made
switch-to-buffer fallback to pop-up-buffer when used in a dedicated
window.  I'll gladly admit that this fallback is wrong, but it's the
sanest way I've found to deal with the wealth of packages calling
switch-to-buffer because the author didn't know better.


        Stefan

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

[Stefan Monnier]

> The trouble was that, when called on a dedicated window, it iconified
> the frame.

I don't follow: why do you think it's a trouble?  To me it's exactly
what I want.  Is it that you prefer it deletes the frame rather than
iconify it?

>> - give `bury-buffer' an extra argument which allows (or forbids) to
>>  delete the selected window (or corresponding frame),
> Perhaps this is the best long term answer.

Not sure if it's needed.  Calling bury-buffer with a non-nil arg should
be sufficient.

>> - make sure that `bury-buffer' deletes only automatically created
>>  windows (much like the recent option `frame-auto-delete').
> What's an "automatically created window"?

Good question.  To me it sounds like "softly dedicated" windows, but
I know Martin hates those, so he is clearly thinking of something else.

> (progn
>   (set-window-dedicated-p (selected-window) t)
>   (bury-buffer))

> still iconifies the frame.

What else would you want it to do?


        Stefan

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

[Juanma Barranquero]

On Tue, Jun 21, 2011 at 18:22, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I don't follow: why do you think it's a trouble?  To me it's exactly
> what I want.  Is it that you prefer it deletes the frame rather than
> iconify it?

No, certainly no.

>> (progn
>>   (set-window-dedicated-p (selected-window) t)
>>   (bury-buffer))
>
>> still iconifies the frame.
>
> What else would you want it to do?

Nothing, other than a message to the user "Attempt to bury buffer in
dedicated window", or something more friendly but equivalent.

 "burying a buffer" /= "iconifying a frame". The fact that the window
is dedicated does not turn that difference suddenly into an equality.

Please note a difference between your use of Emacs and mine: I *never*
use multiple frames. So if I happen to have a dedicated window and I
accidentaly try to bury the buffer, iconifying my only frame is never,
ever going to be useful. It will *always* be followed by de-iconifying
it and then fixing the problem.

Of course, it's not often that I have a single, dedicated window in
the frame. But I use dedicated windows for some things (like the
output of bs-show), and I sometimes do C-x 1 while on one of these
buffers.

    Juanma

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

[Drew Adams]

> > I don't follow: why do you think it's a trouble?  To me it's exactly
> > what I want.  Is it that you prefer it deletes the frame rather than
> > iconify it?
> 
> No, certainly no.
> 
> >> still iconifies the frame.
> > What else would you want it to do?
> 
> Nothing, other than a message to the user "Attempt to bury buffer in
> dedicated window", or something more friendly but equivalent.
> 
>  "burying a buffer" /= "iconifying a frame". The fact that the window
> is dedicated does not turn that difference suddenly into an equality.
> 
> Please note a difference between your use of Emacs and mine: I *never*
> use multiple frames.

FWIW, I typically use multiple frames, and typically with a single buffer each.
Most of my frames are not dedicated, but a few are.

Nevertheless, I agree with Juanma here.  For my purposes, iconification would
always be wrong as part of the behavior of `bury-buffer'.

IIUC, Stefan also uses frames a lot, but he typically (always?) uses
(soft-)dedicated windows.  And he uses a different OS from me, so iconification
might be less annoying for him.

I would like `bury-buffer' to be decoupled from iconification.  I would like
`bury-buffer' to do nothing particular wrt dedicated windows.

Another caveat: I know little about soft-dedication.  Perhaps that makes a
difference to understanding this issue.

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

[Stefan Monnier]

> I would like `bury-buffer' to be decoupled from iconification.  I would like
> `bury-buffer' to do nothing particular wrt dedicated windows.

I'm not sure what "particular" means here.  Part of the drive behind
iconification is that I want bury-buffer to be a sort of
reverse-display-buffer, such that display-buffer followed by bury-buffer
should be a no-op (I know it's not always the case), so as to replace
save-window-excursion with something that does not impose nesting and
that works with frames.


        Stefan

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

[Drew Adams]

> > I would like `bury-buffer' to be decoupled from 
> > iconification.  I would like `bury-buffer' to do
> > nothing particular wrt dedicated windows.
> 
> I'm not sure what "particular" means here.

I explained what it means in the earlier mail:

| [from the doc string:]
|
|  "Also, if BUFFER-OR-NAME is nil or omitted,
|   remove the current buffer from the selected window
|   if it is displayed there."
|
| It is impossible to "remove the current buffer from the
| selected window" if that window is dedicated, so this
| secondary behavior naturally becomes a no-op in that case.
|
| If the window is dedicated, then I'd rather see one of
| these behaviors than I would iconification of the buffer's
| frame:
|
| a. Do nothing wrt the display.  See above: a no-op wrt display.
| b. Delete the frame.
|
| Perhaps the best approach is (a) above: have `bury-buffer'
| just bury the buffer (i.e. affect the buffer order) and
| not have it do anything wrt the display in this case.

IOW, not disappear or move in any way - an unchanged display.  The only effect
would be the change in buffer order that is the raison d'etre of `bury-buffer':
make it least likely to be used as `other-buffer'.

> Part of the drive behind iconification is that I want
> bury-buffer to be a sort of reverse-display-buffer,

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

`bury-buffer' is about reducing the priority of the buffer in the buffer order -
e.g., for `other-buffer'.

Of course display can come into play later, when `other-buffer' (or some other
function) does its thing, which can involve display.  But `bury-buffer' should
not be about affecting the current display of buffers, except in the one case
documented.  At least that would be my preference, I think.

For the case in question (dedicated), if the buffer is to be made to "disappear"
then my (second) choice would be for it to disappear via `delete-frame', not
iconification.

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.

> such that display-buffer followed by bury-buffer should be
> a no-op (I know it's not always the case), so as to replace
> save-window-excursion with something that does not impose
> nesting and that works with frames.

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

[Drew Adams]

> IOW, not disappear or move in any way - an unchanged display. 
> The only effect would be the change in buffer order that is
> the raison d'etre of `bury-buffer': make it least likely to
> be used as `other-buffer'.
>
> `bury-buffer' is not about display.... `bury-buffer' is about
> reducing the priority of the buffer in the buffer order -
> e.g., for `other-buffer'.

Here's another idea: Have `bury-buffer', as I suggested, do nothing wrt display,
but add a hook for it, so users like Stefan can make it also do <whatever> after
just changing the buffer order.  In particular, the <whatever> could play with
the display (iconify or delete frame etc.)

Without doing anything in the hook, a dedicated window/frame/buffer would just
stay there.

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

[Stefan Monnier]

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

The other is when the argument is nil, in which case it is
*specifically* meant to make the buffer disappear (additionally to
changing the buffer-list order).  This case is very much about display,
not just secondarily so.

> 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.  But doing nothing is not an option since the
caller specifically asked to undisplay the buffer.


        Stefan

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.

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

[Stefan Monnier]

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

Indeed you won't be able to convince me.  I know enough about the way
bury-buffer is used throughout the Emacs code to know what is the
intended behavior.

> Instead, it raised the error "Cannot switch buffers in a dedicated window",
> which to me sounds right.

If "breaks most calls to bury-buffer when the window is dedicated"
sounds right to you, then I guess I won't be able to convince
you either.


        Stefan

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

[Juanma Barranquero]

Several bugs related to bury-buffer have been discussed in this thread:

- bs-cycle-next deleting a window
- bs-cycle-next creating a window is the current one is dedicated
- bury-buffer unexpectedly iconizing a frame

but I'm not sure whether some consensus was reached with respect to
how, and where, to fix them. So I'm pinging to get the ball rolling
again.

  J

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

[martin rudalics]

 > - bs-cycle-next deleting a window

I thought Stefan's proposal to call `bury-buffer' with the current
buffer as explicit argument should handle this.

martin

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

[Juanma Barranquero]

> I thought Stefan's proposal to call `bury-buffer' with the current
> buffer as explicit argument should handle this.

True, thanks. I've committed that fix.

What about the other two?

    Juanma

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

[Stefan Monnier]

>> I thought Stefan's proposal to call `bury-buffer' with the current
>> buffer as explicit argument should handle this.

> True, thanks. I've committed that fix.
> What about the other two?

I'm not sure about the third (isn't it also fixed by passing a non-nil
arg to bury-buffer?), but for the second the right fix is to remove the
"fallback on pop-to-buffer" from switch-to-buffer.  Of course, that will
(re)introduce new bugs which we could/should "fix" by marking
switch-to-buffer (and find-file and maybe a few more) as "don't call
from Elisp".


        Stefan

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

[Juanma Barranquero]

On Mon, Jun 27, 2011 at 03:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I'm not sure about the third (isn't it also fixed by passing a non-nil
> arg to bury-buffer?)

Well, yes, but that means "fixing" it everywhere; I mean:

emacs -Q
M-: (set-window-dedicated-p (selected-window) t) <RET>
M-x bury-buffer <RET>

and the frame is iconified. It shouldn't.

> but for the second the right fix is to remove the
> "fallback on pop-to-buffer" from switch-to-buffer.  Of course, that will
> (re)introduce new bugs which we could/should "fix" by marking
> switch-to-buffer (and find-file and maybe a few more) as "don't call
> from Elisp".

If switch-to-buffer is changed not to fallback on pop-to-buffer, why
shouldn't it be called from elisp? In the case of bs-cycle-next:

        (unless (window-dedicated-p (selected-window))
          ;; We don't want the frame iconified if the only window in the frame
          ;; happens to be dedicated
          (bury-buffer (current-buffer)))
        (switch-to-buffer next)

the current switch-to-buffer causes the unwanted-splitting behavior.
Changing it to pop-to-buffer-same-window, as its docstring suggests,
would still cause the same problem.

    Juanma

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

[martin rudalics]

 > If switch-to-buffer is changed not to fallback on pop-to-buffer, why
 > shouldn't it be called from elisp? In the case of bs-cycle-next:
 >
 >         (unless (window-dedicated-p (selected-window))
 >           ;; We don't want the frame iconified if the only window in the frame
 >           ;; happens to be dedicated
 >           (bury-buffer (current-buffer)))
 >         (switch-to-buffer next)
 >
 > the current switch-to-buffer causes the unwanted-splitting behavior.
 > Changing it to pop-to-buffer-same-window, as its docstring suggests,
 > would still cause the same problem.

`switch-to-buffer' has a specific window show a specific buffer.  The
user cannot change that via options.

`pop-to-buffer-same-window' tries to show a specific buffer in a
specific window.  But the user can change that via options.  In
particular, the user can decide to override the splitting behavior,
dedicatedness of windows, ...  All `bs-cycle-next' has to do is call
it via

(pop-to-buffer-same-window next nil 'bs-cycle-next)

martin

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

[Juanma Barranquero]

On Mon, Jun 27, 2011 at 09:00, martin rudalics <rudalics@gmx.at> wrote:

> `switch-to-buffer' has a specific window show a specific buffer.  The
> user cannot change that via options.

Understood.

> `pop-to-buffer-same-window' tries to show a specific buffer in a
> specific window.  But the user can change that via options.  In
> particular, the user can decide to override the splitting behavior,
> dedicatedness of windows, ...

In the specific case of bs-cycle-next, for non-dedicated windows,
(pop-to-buffer-same-window next) works.

> All `bs-cycle-next' has to do is call
> it via
>
> (pop-to-buffer-same-window next nil 'bs-cycle-next)

Presumably you mean all is needed is that, plus an entry in
`display-buffer-alist'. But I don't see a way to say "OK, abort, this
window is strongly dedicated so the buffer shouldn't be shown
anywhere, just throw an error to the user". Care to show how to say
that?

TIA,

    Juanma

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

[martin rudalics]

 > Presumably you mean all is needed is that, plus an entry in
 > `display-buffer-alist'.

If the user wants to change the default behavior, yes.

 > But I don't see a way to say "OK, abort, this
 > window is strongly dedicated so the buffer shouldn't be shown
 > anywhere, just throw an error to the user". Care to show how to say
 > that?

I'm not sure whether we want to do that.  If so, there are two ways.
Either, in `bs-cycle-next' write something like:

   (if (and (window-dedicated-p) (not (eq (window-buffer) next)))
       (error "Selected window is dedicated to its buffer")
     (display-buffer-same-window next))

which gives the user no choice wrt what to do when the selected window
is dedicated or write

(defun reuse-same-window-unless-dedicated (buffer &rest args)
   "..."
   (if (and (window-dedicated-p) (not (eq (window-buffer) next)))
       (error "Selected window is dedicated to its buffer")
     (display-buffer-same-window buffer)))

(display-buffer
   next '((fun-with-args reuse-same-window-unless-dedicated)) 'bs-cycle-next)

and allow the user to specify her own deviant behavior when the selected
window is dedicated.

martin

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

[Juanma Barranquero]

On Mon, Jun 27, 2011 at 14:46, martin rudalics <rudalics@gmx.at> wrote:

> If the user wants to change the default behavior, yes.

Ah. Current documentation for display-buffer-alist is less than clear to me.

> I'm not sure whether we want to do that.

Well, I'm not sure whether *we* want, either, but I'm definitely sure
I want (locally, I mean).

> If so, there are two ways.
> Either, in `bs-cycle-next' write something like:
>
>  (if (and (window-dedicated-p) (not (eq (window-buffer) next)))
>      (error "Selected window is dedicated to its buffer")
>    (display-buffer-same-window next))
>
> which gives the user no choice wrt what to do when the selected window
> is dedicated

I supose this is a no-no.

>  or write
>
> (defun reuse-same-window-unless-dedicated (buffer &rest args)
>  "..."
>  (if (and (window-dedicated-p) (not (eq (window-buffer) next)))
>      (error "Selected window is dedicated to its buffer")
>    (display-buffer-same-window buffer)))
>
> (display-buffer
>  next '((fun-with-args reuse-same-window-unless-dedicated)) 'bs-cycle-next)
>
> and allow the user to specify her own deviant behavior when the selected
> window is dedicated.

I don't follow you. reuse-same-window-unless-dedicated is throwing an
error unconditionally. How would the user specifiy her own behavior?

    Juanma

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

[martin rudalics]

 > I don't follow you. reuse-same-window-unless-dedicated is throwing an
 > error unconditionally. How would the user specifiy her own behavior?

Using the override specifier and matching the bs-cycle-next label.  The
override specifier should do what it says - override everything the
application proposes.  The label is needed since `bs-cycle-next' can pop
up an arbitrary buffer no regexp or name could selectively match.

martin

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

[Juanma Barranquero]

On Mon, Jun 27, 2011 at 16:12, martin rudalics <rudalics@gmx.at> wrote:

> Using the override specifier and matching the bs-cycle-next label.  The
> override specifier should do what it says - override everything the
> application proposes.

I'm quite sure I will be able to do that, as soon as I'm able to
understand display-buffer-alist's docstring. For the moment I find it
quite obscure.

> The label is needed since `bs-cycle-next' can pop
> up an arbitrary buffer no regexp or name could selectively match.

Yes, that at least I understand. And I'm sure once I grok the rest it
will help simplifying my .emacs (for example, I will not need to
strongly dedicate *buffer-selection*).

    Juanma

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

[Juanma Barranquero]

This code, which is mostly Martin's, fixes case 2. The user can
override the "signal error" behavior by customizing
display-buffer-alist or adding

(push '(((label . bs-cycle-next)
         (label . bs-cycle-previous))
        reuse-window
        (reuse-window same nil nil)
        (reuse-window-dedicated . t)
        (override . t))
      display-buffer-alist)

to their .emacs.

OK to install?

   J


=== modified file 'lisp/bs.el'
--- lisp/bs.el	2011-06-27 01:52:37 +0000
+++ lisp/bs.el	2011-06-27 19:59:41 +0000
@@ -1190,6 +1190,15 @@
 (defvar bs--cycle-list nil
   "Current buffer list used for cycling.")

+(defun bs--reuse-window-unless-dedicated (buffer &rest _args)
+ "Display BUFFER in the selected window.
+If the selected window is dedicated, signal an error instead.
+This function is intended to be called from `display-buffer'.
+To override it, see `display-buffer-alist'."
+ (if (and (window-dedicated-p) (not (eq (window-buffer) buffer)))
+     (error "Selected window is dedicated to its buffer")
+   (display-buffer-same-window buffer)))
+
 ;;;###autoload
 (defun bs-cycle-next ()
   "Select next buffer defined by buffer cycling.
@@ -1215,7 +1224,9 @@
         ;; We don't want the frame iconified if the only window in the frame
         ;; happens to be dedicated.
         (bury-buffer (current-buffer))
-	(switch-to-buffer next)
+	(display-buffer next
+			'((fun-with-args bs--reuse-window-unless-dedicated))
+			'bs-cycle-next)
 	(setq bs--cycle-list (append (cdr cycle-list)
 				     (list (car cycle-list))))
 	(bs-message-without-log "Next buffers: %s"
@@ -1244,7 +1255,9 @@
 					    bs--cycle-list)))
 	     (prev-buffer (car tupel))
 	     (cycle-list (cdr tupel)))
-	(switch-to-buffer prev-buffer)
+	(display-buffer prev-buffer
+			'((fun-with-args bs--reuse-window-unless-dedicated))
+			'bs-cycle-previous)
 	(setq bs--cycle-list (append (last cycle-list)
 				     (reverse (cdr (reverse cycle-list)))))
 	(bs-message-without-log "Previous buffers: %s"

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

[Stefan Monnier]

>> I'm not sure about the third (isn't it also fixed by passing a non-nil
>> arg to bury-buffer?)
> Well, yes, but that means "fixing" it everywhere; I mean:
> emacs -Q
> M-: (set-window-dedicated-p (selected-window) t) <RET>
> M-x bury-buffer <RET>
> and the frame is iconified.  It shouldn't.

As mentioned earlier, maybe the single-frame case is special, but I'd
really first like to know how you get into such a state.  For any other
case, M-x bury-buffer RET *should* iconify the current frame if it shows
a single dedicated window (with the caveat that Drew wants it to delete
the frame instead).

> If switch-to-buffer is changed not to fallback on pop-to-buffer, why
> shouldn't it be called from elisp?

Because 99% of the calls are wrong (they just want to display
a specific buffer and the author did not consider what should happen if
called in a minibuffer-only frame or in a dedicated window).

> In the case of bs-cycle-next:

>         (unless (window-dedicated-p (selected-window))
>           ;; We don't want the frame iconified if the only window in the frame
>           ;; happens to be dedicated
>           (bury-buffer (current-buffer)))
>         (switch-to-buffer next)

> the current switch-to-buffer causes the unwanted-splitting behavior.
> Changing it to pop-to-buffer-same-window, as its docstring suggests,
> would still cause the same problem.

Yes, bs-cycle-next would be one of the very rare cases where calling
switch-to-buffer is the right thing to do.


        Stefan

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

[Juanma Barranquero]

On Wed, Jun 29, 2011 at 05:27, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> As mentioned earlier, maybe the single-frame case is special, but I'd
> really first like to know how you get into such a state.

As I explained, I have strongly-dedicated windows, and every now and
then I end doing C-x 1 inside one of them. As it isn't usually what I
wanted, I immediately do <f10> (which I have bound to bs-cycle-next).
But, leaving aside my own use case, yeah, for the single frame use
case, iconifying it is hardly going to be useful for anyone, I think.

> For any other
> case, M-x bury-buffer RET *should* iconify the current frame if it shows
> a single dedicated window (with the caveat that Drew wants it to delete
> the frame instead).

I don't even agree with your example, because I certainly wouldn't
want my frames iconified (and, in any case, I'd use M-x iconify-frame
<RET> for that). But explicit interactive calls of bury-buffer are not
what I complain about; I don't mind these, because I just don't ever
use them. My problem happens when bury-buffer is called from some
elisp code that does a poor job of reading my mind: no, mr. program, I
don't really want my frames iconified, thank you very much.
bs-cycle-next is just the most prominent example of that bad behavior,
because I use it a lot.

So, I don't mind which is the default, as long as there's a way to
customize it (with Martin's new window machinery, not redefining
functions) to my tastes.

    Juanma

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

[Stefan Monnier]

>> As mentioned earlier, maybe the single-frame case is special, but I'd
>> really first like to know how you get into such a state.
> As I explained, I have strongly-dedicated windows, and every now and
> then I end doing C-x 1 inside one of them. As it isn't usually what I

Where do these strongly dedicated windows come from?

>> For any other case, M-x bury-buffer RET *should* iconify the current
>> frame if it shows a single dedicated window (with the caveat that
>> Drew wants it to delete the frame instead).

> <RET> for that). But explicit interactive calls of bury-buffer are not
> what I complain about; I don't mind these, because I just don't ever
> use them.

Good.

> My problem happens when bury-buffer is called from some
> elisp code that does a poor job of reading my mind: no, mr. program, I
> don't really want my frames iconified, thank you very much.

Please report these cases.  I suspect that in most cases the problem is
not bury-buffer's behavior but that the command should not call
bury-buffer (or not with a nil arg).

> bs-cycle-next is just the most prominent example of that bad behavior,
> because I use it a lot.

That's indeed a case where (bury-buffer nil) was the wrong thing to do.


        Stefan

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

[Juanma Barranquero]

On Thu, Jun 30, 2011 at 19:02, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Where do these strongly dedicated windows come from?

I set them in hooks; for example I do it with *buffer-selection*
because I never want to switch to another buffer in the window that I
use for temporary buffers.

I think some of my uses can be simplified with Martin's changes, and
indeed I will be doing a careful inspection of my .emacs looking for
things to remove...

> Please report these cases.

Will do.

    Juanma

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

[Juanma Barranquero]

On Thu, Jun 30, 2011 at 20:50, Juanma Barranquero <lekktu@gmail.com> wrote:

Both complains about bs-cycle-next have been solved, and any
bury-buffer issue should be reported separately, so I'm closing this
bug.

    Juanma

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

[martin rudalics]

 > Because 99% of the calls are wrong (they just want to display
 > a specific buffer and the author did not consider what should happen if
 > called in a minibuffer-only frame or in a dedicated window).

Why aren't minibuffer-only frame windows automatically dedicated?

martin

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

[Stefan Monnier]

>> Because 99% of the calls are wrong (they just want to display
>> a specific buffer and the author did not consider what should happen if
>> called in a minibuffer-only frame or in a dedicated window).
> Why aren't minibuffer-only frame windows automatically dedicated?

Maybe just because they predate the notion of dedicatedness?
Or because a minibuffer-only frame will show different buffers at
different times (think of echo-area buffers, recursive minibuffers,
...), so "dedicated" isn't quite right.


        Stefan

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

[Juanma Barranquero]

On Wed, Jun 29, 2011 at 05:27, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Yes, bs-cycle-next would be one of the very rare cases where calling
> switch-to-buffer is the right thing to do.

Which is exactly what the patch I sent for case 2 (bs-cycle-next vs.
dedicated windows) does. It's OK to install, or do you object to it?

    Juanma

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

[Drew Adams]

> M-x bury-buffer RET *should* iconify the current frame
> if it shows a single dedicated window (with the caveat
> that Drew wants it to delete the frame instead).

So...it *SHOULD*...(but Drew wants something different).  Hm.

"Drew wants".  What Drew might want for his personal use is one thing.  What
Drew wants for Emacs is another thing.  In either case you misrepresent what
Drew wants.

I made it clear that I did _not_ "want it to delete the frame instead".  That is
_not_ the behavior I prefer for Emacs, and it is not even my preference for my
own use all of the time.

I said, speaking about the dedicated-window case:

> the best approach is (a) above: have `bury-buffer'
> just bury the buffer (i.e. affect the buffer order) and
> not have it do anything wrt the display in this case.
>
> IOW, not disappear or move in any way - an unchanged display.
> The only effect would be the change in buffer order that is
> the raison d'etre of `bury-buffer': make it least likely to
> be used as `other-buffer'.

NO deletion and NO iconification, by default.
That's what Drew wants for Emacs.

But also with the possibility for a _user_ to add deletion or iconification - or
anything else s?he might like.  I said that we should give users control.  

Users who, like Stefan, might want `bury-buffer' for a dedicated window to
always be accompanied by iconification, and users who might want it to instead
always delete the frame, should be able to get what they want.

But also users who might want `bury-buffer' to iconify in context A, delete in
context B, thumbify in context C, and do nothing at all to the display in
context D -- those users too should be able to get the behavior they prefer.

There's nothing holy about Stefan's or Drew's preferences for personal use -
those personal preferences should not preclude other users from getting other
behaviors that they prefer.

I proposed adding a `bury-buffer-hook', which users can use to do anything they
like after `bury-buffer' changes the buffer order:

> so users like Stefan can make it also do <whatever> after
> just changing the buffer order.  In particular, the <whatever>
> could play with the display (iconify or delete frame etc.)
>
> Without doing anything in the hook, a dedicated
> window/frame/buffer would just stay there.

Simple, clean, easy to use, decoupled.
Flexible for different contexts.

Stefan countered with a (reluctant "Drew wants") proposal to add an option to
give users just a little control of the display behavior:

S> add an option so that bury-buffer uses delete-frame
S> instead of iconify-frame. 

But he refused to let users (a) do _nothing_ in terms of display (e.g. leave the
dedicated window/frame, with its buried buffer) or (b) do something different
altogether.

The option he proposed does not let users choose any other behavior (or no
behavior), besides deletion and iconification.  And naturally he wants
iconification to be the default.

My argument isn't to delete the frame.
My argument is to give the _user_ control.

My argument is that `bury-buffer' is essentially about changing the buffer
order, and any choice about what to do (if anything) about the _display_ of the
buried buffer (delete, iconify, leave alone,...) should be the _user's_ choice,
not Stefan's choice hard-wired into the design.

Even if you insisted on prepopulating the hook so that the _default_ behavior
was whatever you prefer (e.g. iconifying), what I would like is for users to
have real control over the behavior - not just some binary option to delete
instead of iconify.  That's what "Drew wants".

If you refuse to give the user real control, however, and you insist on coupling
some display behavior with the changing of the buffer order (`bury-buffer's
raison d'etre), then yes, in that desperate case _only_, I said:

> _if_ the buffer is to be made to "disappear" then my (second) choice
> would be for it to disappear via `delete-frame', not iconification.

But why not let users get whatever behavior they want, easily?
Why insist on deciding for them?

We know we want `bury-buffer' to bury the buffer: change the buffer order.
That's not in question.  What's not agreed upon is what else it should do,
particularly in the case of a dedicated window.  I say, let users themselves
decide.

Buffer display, and especially so for dedicated windows, can be a complex,
personal matter.  Please don't force automatic frame iconification (or deletion
for that matter) on everyone.  There's no need for that.

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

[Drew Adams]

> Even if you insisted on prepopulating the hook so that the 
> _default_ behavior was whatever you prefer (e.g. iconifying),
> what I would like is for users to have real control over
> the behavior - not just some binary option to delete
> instead of iconify.

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.

E.g., a function to be invoked after the buffer order is changed.  Function
`ignore' would take care of the do-nothing case.  The function would need to
accept the buffer as its (first) argument.

What I object to is Stefan's proposal of an option that allows only a choice
between deleting the frame and iconifying it.

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

[martin rudalics]

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

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

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

 > What I object to is Stefan's proposal of an option that allows only a choice
 > between deleting the frame and iconifying it.

martin

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

[Drew Adams]

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

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

[Stefan Monnier]

> Please note a difference between your use of Emacs and mine: I *never*
> use multiple frames. So if I happen to have a dedicated window and I
> accidentaly try to bury the buffer, iconifying my only frame is never,
> ever going to be useful. It will *always* be followed by de-iconifying
> it and then fixing the problem.

Iconifying should only happen if the window is dedicated *and* it's the
only window in the frame.  How do you ever get into such a state in your
single-frame use?

> Of course, it's not often that I have a single, dedicated window in
> the frame. But I use dedicated windows for some things (like the
> output of bs-show), and I sometimes do C-x 1 while on one of these
> buffers.

Ah... I guess we could work around the problem by deciding that we
should additionally check that there's some other frame displayed before
iconifying a frame.
Not sure what a real fix would look like.


        Stefan

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

[martin rudalics]

 >> The trouble was that, when called on a dedicated window, it iconified
 >> the frame.
 >
 > I don't follow: why do you think it's a trouble?  To me it's exactly
 > what I want.  Is it that you prefer it deletes the frame rather than
 > iconify it?

No.  But I recall that people disliked iconified frames.

 > Not sure if it's needed.  Calling bury-buffer with a non-nil arg should
 > be sufficient.

Indeed, that's the best solution.

martin

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

[Drew Adams]

Caveat: I have not really been following this thread closely.

> > The trouble was that, when called on a dedicated window, it 
> > iconified the frame.
> 
> I don't follow: why do you think it's a trouble?  To me it's exactly
> what I want.  Is it that you prefer it deletes the frame rather than
> iconify it?

FWIW, iconifying is not what I would prefer.

`bury-buffer' is primarily about buffer order.  It's about getting the buffer
out of the way for `other-buffer'.

Only secondarily is it at all about display (almost as an afterthought):

"Also, if BUFFER-OR-NAME is nil or omitted,
remove the current buffer from the selected window if it is
displayed there."

It is impossible to "remove the current buffer from the selected window" if that
window is dedicated, so this secondary behavior naturally becomes a no-op in
that case.

If the window is dedicated, then I'd rather see one of these behaviors than I
would iconification of the buffer's frame:

a. Do nothing wrt the display.  See above: a no-op wrt display.
b. Delete the frame.

Iconifying can be annoying, depending on your OS.  I really don't see it as
appropriate for `bury-buffer'.  If code wants to iconify the frame it can always
do so explicitly.  Likewise for frame deletion, of course.

Perhaps the best approach is (a) above: have `bury-buffer' just bury the buffer
(i.e. affect the buffer order) and not have it do anything wrt the display in
this case.


Wrt `bs-cycle-next': I'm no expert on that (I don't use it), but wouldn't it
make sense for this kind of thing to _not_ affect the order of the default
buffer list, but rather to cycle its own copy/version of that list?

In that case, `bs' could decide how to handle buffers in dedicated windows for
its own purposes (cycling display), without altering the standard buffer order.
This would decouple `bs' cycling from `other-buffer' - would that be a good/bad
thing?  Dunno.

E.g., A priori, I see no reason why a buffer in a dedicated window should be
removed from the buffer list (by `bs-cycle-next' etc.).

The requirement seems to be only for `bs-cycle-next' to ignore that buffer or
skip over it or something.  But why should that action alter the standard buffer
list?

Again, I haven't followed this, and I know very little about `bs' etc.  If what
I say makes no sense, please ignore it.