RE: switch-to-buffer-other-frame fails to pop-up window

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

> >  > what use case would clash with a change like this?
> >
> > I don't know, maybe there is one.  We could try to provide a third value
> > for `pop-up-frames': If it's 'force `display-buffer' would _always_ try
> > to display the buffer in a new frame regardless of how many times it is
> > already displayed.  What do you think?
>
> that would certainly provide a work-around and make me happy.
>
> but i'm still curious why the intent of pop-up-frames is overridden by
> display-buffer.  there has to be a reason lurking somewhere?

I like the way it works. The use case is that what one is after is for the
buffer to be displayed - that's all. I use non-nil `pop-up-frames' to have
`display-buffer' show a buffer for the first time in a new frame, but not to
always show a buffer in a new frame. That's what `pop-up-frames' is about.

BTW, this is not `display-buffer' _overriding_ `pop-up-frames'; the latter
is made for the former. `pop-up-frames' has no meaning other than for
`display-buffer'.

The relevant doc is the doc string of `display-buffer'. The doc string of
`pop-up-frames' tries to take the shortcut of referring to `display-buffer',
but it should be clearer about what happens if the buffer is already shown
in a frame somewhere. The doc string of `display-buffer' is clear about
this:

 "If `pop-up-frames' is non-nil, make a new frame
  if no window shows BUFFER."

It is the last bit of the logic ("if no window shows BUFFER") that is
missing from the doc string of `pop-up-frames'.

In principle, we could add a new `force' value for `pop-up-frames'. But
there is  existing code that tests `pop-up-frames' and assumes the current
behavior. In some cases, it uses `pop-up-frames' as a guide to user
intentions and practice wrt frames in general. At least some of that code
would likely need to be revisited, to see if the test is still sufficient or
should be changed to test non-nil and non-`force'.