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

[martin rudalics]

> 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