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

[Drew Adams <drew.adams@oracle.com>]

> 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.

Why would someone choose to use an `other-frame'
command to get some behavior other than `other-frame'?

Especially since there are other bookmark jumping
commands that do not use another frame?  The point
of the thread that this discussion responds to was
to add an other-frame bookmark jump command.  We
already have other bookmark-jump commands for the
same window and for another window.

And it is trivial to define your own bookmark jump
command to do whatever you like that is special,
whether for a specific bookmark, specific jump
behavior, or whatever.

In particular, predefined command `bookmark-jump',
and some other jump commands, just invoke the
general function `bookmark--jump-via', which accepts
(surprise!) a DISPLAY-FUNCTION argument.

That's the _only_ difference between some of those
jump commands: the DISPLAY-FUNCTION argument passed.

But since `bookmark-jump' itself accepts an optional
DISPLAY-FUNCTION argument (which it just passes on
to `bookmark--jump-via'), you can just as well call
`bookmark-jump' instead of `bookmark--jump-via'.
And BTW, that's what `bookmark-jump-other-window' does.

And yes, if one prefers, `bookmark-jump-other-frame'
could also be defined the same way (either of those
ways).  Or it could be defined by calling
`bookmark-jump-other-window' while binding
`pop-up-frames'.  It doesn't matter to me which
approach is taken for that.  And it shouldn't matter
to users - same behavior, AFAIK.

> If this command forces the use of the
> selected frame by binding some global variable instead of passing an
> appropriate action argument,

If the action argument passed just says to use another
frame then the result is the same, no?  It certainly
seems the same in the question at hand,
`bookmark-jump-other-frame'.  In both cases the
command "forces the use" of some particular display
action.

> 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.

A command that calls `switch-to-buffer' has different
behavior from one that pops to a buffer in another
window or frame.  So what?  We have different commands
for these possibilities.  Each of those commands
"inhibits the user", providing only a specific
buffer-display behavior.

(But not `bookmark-jump' (or `bookmark--jump-via',
which is not a command) - it doesn't inhibit using it
to display a buffer anyway you like.)

>  > 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.

Each of those specific bookmark jump commands
specifies a particular buffer-display behavior
(except `bookmark-jump', which accepts a behavior
argument).  Is that what you call the application
overriding it?

Again, if you want specific display behavior you
can get it.  If you want one of the predefined
behaviors you can have that too.