> (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. _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
