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

[martin rudalics <rudalics@gmx.at>]

 > And BTW, it makes perfect sense for a command
 > that acts just like an other-window command, but
 > uses other-frame instead of other-window, to
 > bind `pop-up-frames'.
 >
 > That's precisely the meaning of `pop-up-frames':
 > make other-window commands use other-frame.

No.  The call to that command might conflict with the user's intention
to usually pop up a new frame for most buffers but to not pop up a new
frame for some _specific buffer_ whose name is specified in
'display-buffer-alist'.  The binding of 'pop-up-frames' might defeat
precisely that latter intention (even if we do our best to avoid it).

 > We create user options for user convenience.
 > They are not something that should limit users.

Overriding the customization of 'display-buffer-alist' does limit the
user.

 > Did anyone tell programmers that they must always
 > bind a variable instead of passing an argument to
 > a function?  I don't think so.

On the contrary we tell programmers to not bind a variable and always
pass an argument instead.

 > What's your problem with that thread?  I guess
 > it's this code:
 >
 > (let ((pop-up-frames  t))
 >    (bookmark-jump-other-window bookmark))
 >
 > Nothing could be simpler, clearer, or more
 > elegant for a command that jumps to a bookmark
 > in another frame, IMO.

Unless it's a specific bookmark the user wants to handle specifically.

 > Now I even wonder, since you pointed to that
 > thread, whether my showing `pop-up-frames'
 > there was perhaps a catalyst for your recent
 > discouragement of `pop-up-frames' in the doc.

Quite on the contrary.  The only thing I appreciated in that thread
was what you wrote (and cited here).

martin