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

[martin rudalics <rudalics@gmx.at>]

 > Not to mention that you cannot "always pass an argument"
 > instead.

The canonical way for a program to affect the behavior of
'display-buffer' is to pass an argument.  Everything else is
discouraged.  'display-buffer-overriding-action' is the only
construct to override the user and should be used with care.

 > Not without recoding the world, at least.  See
 > RMS's article for good, simple examples.
 >
 > Emacs Lisp is for Emacs - an interactive program.  Sure,
 > all of the advantages of lexical scoping are nice, but
 > performance, for example, is in many instances not as
 > important for Emacs as for other programming contexts.
 > Optimization is, for Emacs, a nice-to-have, in general.
 >
 > Likewise, the better ability to reason about program
 > behavior that lexical scoping brings.  Likewise, the
 > reduced funarg problems.
 >
 > But (1) we have lexical scoping now (and I, for one,
 > am in favor of it being on by default, as in Common
 > Lisp), and (2) if we really want solid semantic
 > behavior (no funarg problems at all) then we should
 > move to a purely functional, fully lazy language.
 > I don't see #2 happening, and it need not.  Emacs
 > Lisp is a good language for Emacs.

What do all these have to do with the subject at hand?

 >> Unless it's a specific bookmark the user wants to handle specifically.
 >
 > Maybe you meant "buffer" instead of "bookmark".

I meant bookmark - a position in a buffer stored for later perusal.
Why else would we be discussing 'display-buffer' in this context?

 > (I often make that typo, in both directions.)
 >
 > But maybe you did mean bookmark.  And the bookmark
 > code gives you the possibility of treating specific
 > bookmarks differently.  And this code is for a
 > _command_ whose job is specifically to pop to the
 > bookmark in another frame.  If you don't want that
 > behavior for a particular bookmark then you won't
 > use that command - you'll use a different command.

This command would be for usually popping up the bookmark in another
frame and the user would know that.  However, for certain, specified
bookmarks the user might want to use the selected frame instead and
still use the same command.  If this command forces the use of the
selected frame by binding some global variable instead of passing an
appropriate action argument, it inhibits the user to customize its
behavior.  Just like calling 'switch-to-buffer' inhibits the user to
pop to a buffer in another window or frame.

 > So there are multiple ways around your problem.
 > Two of them are: (1) specify specific behavior for
 > a specific bookmark and (2) use a different command.
 >
 > If you do want specific _buffers_ to be handled
 > specially then you can of course have recourse to
 > the general toolkit that is `display-buffer-alist'.
 > No problem.

Unless the application overrides it.

martin