Subject: RE: bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames'

From: "Drew Adams" <[email-masked]>
Date: Tue, 14 Jun 2011 12:43:16 -0700

>  > I have non-nil `pop-up-frames'.  I use the following 
>  > function via `M-x find-library-other-window frame.el'.
>  > It should find the library in a separate frame.
>  > Instead, it finds it in another window of the current
>  > frame - i.e., it splits the current window and puts it in 
>  > one of those two windows.
> 
> Emacs has a lot of commands postfixed with -other-window and
> -other-frame.  For example, `find-file-other-window' or
> `switch-to-buffer-other-window' traditionally find a file or 
> switch to a buffer in another window on the same frame.

Yes, and they all pop up a separate frame, if `pop-up-frames' is non-nil.  This
has _always_ been the case, ever since Emacs introduced frames.  And it should
continue to be the case.

And the doc of `pop-up-frames' (in (elisp) Choosing Window) says so:

 This variable specifies whether `display-buffer' should make new
 frames.  If it is non-`nil', `display-buffer' looks for a window
 already displaying ... If it finds such a window...
 Otherwise it makes a new frame...

Otherwise it makes a new frame.  Period.

And it says, further reinforcing the point:

 If `pop-up-frames' is `nil', then `display-buffer' either
 splits a window or reuses one.

It does that only if the option value is nil.

But in the latest build, this is broken.  Try, in last weeks build (or last
year's or 1990's build or...):

emacs -Q
(setq pop-up-frames t)
C-x 4 f foo.el

The file is visited in a separate frame.  Not so in this week's build.  The same
is true for _all_ `C-x 4' prefix commands.  Non-nil `pop-up-frames' treats all
`C-x 4' keys as if they were `C-x 5' keys.  It makes `*-other-window' commands
behave as `*-other-frame' commands.  Always has.  Always should.

> By this convention,
> `find-library-other-window' is not supposed to pop up a new frame.

Of course it is.  Just like all the others.

> If we want to maintain compatibility with the old behavior in this and
> similar cases we'd have to segregate a set of reserved values for the
> second argument of `display-buffer'.  Preserving the classic "non-nil"
> behavior is impossible if we want to use the new `display-buffer' code

If it ain't broke, don't fix it.  If there are some problems that you would like
to fix for people who do not use non-nil `pop-up-frames', do so, but not by
breaking Emacs for people who do use non-nil `pop-up-frames', please.

> (originally I favored let-binding to achieve that behavior 
> but using an
> argument was proposed by Stefan Monnier and overloading the second
> argument by Juri Linkov - at the time that was discussed there were no
> objections).

I have nothing to say about how to implement your new features.  My point is to
please not, as a side effect, also break Emacs for non-nil `pop-up-frames'.

> I have no objections interpreting the argument value `t' in the sense
> that when `pop-up-frames' is non-nil and not unset, `display-buffer'
> tries to pop up a new frame before it tries to pop up a new window.

I'm not sure I understand what you're saying (what argument? etc.).  But if you
are saying that you will restore the behavior that non-nil `pop-up-frames'
causes `display-buffer' to do what the doc says it should do, and what it always
has done, then yes, I'm in favor of that.  That means:

 `display-buffer' looks for a window already displaying
 BUFFER-OR-NAME on any visible or iconified frame. If it finds such
 a window, it makes that window's frame visible and raises it if
 necessary, and returns the window.  Otherwise it makes a new frame,
 unless the variable's value is `graphic-only' and the selected
 frame is not on a graphic display.

(Non-nil is not the same as non-t, BTW, for both `pop-up-frames' and the
NOT-THIS-WINDOW arg of `display-buffer'.  If you were speaking about that arg,
then any non-nil value has always had the same behavior as a value of t.  Or if
you were speaking of `pop-up-frames', then the only special non-nil value is
`graphic-only', not t, and even that value is special only for non-graphic
displays.)