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

[martin rudalics]

> 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