RE: mail-bury should use one-window-p, not window-dedicated-p

[Drew Adams]

>     (window-dedicated-p (frame-selected-window))
>     to this:
>     (and pop-up-frames (one-window-p))
>
> I think it is correct to test the first one.
> It may be desirable to test the second as well.
> Let's try it out for a while.

I hope you mean try both tests, not just the first.

You're right that the two cases are independent: some people might use
dedicated windows (here and there, or everywhere); others might use non-nil
`pop-up-frames'; and neither test covers the other.

Using non-nil `pop-up-frames' is more general (less restrictive) than using
dedicated windows. It requires only that `display-buffer' create a new frame
if the buffer is not already displayed. You can still split windows and
reuse windows with different buffers. It is closer to the mainstream Emacs
use of windows than is a generalized use of dedicated windows.

If you have a single-window frame and you've elected `pop-up-frames', then I
think it makes sense for the frame to be discarded when the buffer displayed
there is.

Here, I'm making an interpretation, admittedly. It's true that that does not
follow simply from a choice to let `display-buffer' use a new frame. It is
based on my experience with `pop-up-frames' and questions and requests I've
seen from others: I think that most people, once they adopt non-nil
`pop-up-frames', expect the frame to go bye-bye when they kill its current
buffer, and they are surprised when it sometimes does not. To ensure that
behavior, some of us end up redefining miscellaneous functions such as
`mail-bury' locally, which shouldn't be necessary.

If Emacs developers feel that one-window-p frame deletion should not be
tightly coupled with `pop-up-frames' = t, then perhaps we should let
`pop-up-frames' have three values: nil and t as now, and `auto-discard', the
latter causing the behavior that I prefer: whenever the frame is
one-window-p and the current buffer is discarded (e.g. buried or killed),
delete the frame also.