Re: `pop-up-frames' and binding/setting user options [was: Documenting buffer display]

[martin rudalics <rudalics@gmx.at>]

 > Sure, we both acknowledged that.  But why would you
 > choose to use an `other-frame' command for those
 > specific bookmarks for which it is not TRT?  That's
 > the question.

Because it might be the nearest existing approximation of what the
user wants.

 > Is your argument against `pop-up-frames' only that
 > of a maintainer - not wanting to bother maintaining
 > support?  Or is it that you see it as a bad thing
 > for users to be able to use `pop-up-frames'?
 >
 > Saying that in some case (which I haven't seen
 > demonstrated yet) it doesn't do the same thing that
 > passing an equivalent argument does, does not
 > invalidate its usefulness.  At most it would be an
 > argument for not using it in those hypothetical
 > problematic cases.

'pop-up-frames' cannot be considered in isolation.  It is accompanied
by two additional options - 'pop-up-frame-function' which specifies
the function to call when 'pop-up-frames' is non-nil and
'pop-up-frame-alist' which specifies the parameters passed to that
function.  The implementation of the latter is not guaranteed to
always do what the user wants as I now mention in the manual text and
I have no idea how to fix that.  IMO 'display-buffer-pop-up-frame'
should never have used 'pop-up-frame-function' and
'pop-up-frame-alist' in the first place.  This is a design flaw that
AFAICT cannot be corrected at the present stage without introducing
yet another behavioral incompatibility.  And it has minor importance
because there is no need to use 'pop-up-frames' nowadays.

martin