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

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

> > 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 the user doesn't want to have to think about it.  So he always
> uses the same key-binding and then configures display-buffer-alist to
> adjust the behavior for those corner cases where another frame is not
> the right destination.

Nothing wrong with doing that.  That's similar to
using `special-display-buffer-names'.  (Not the same,
but similar.)

There are alternative ways to get such an effect
(including by doing the same thing for a different
one of the bookmark-jump commands).  We have
same-window, other-window, and other-frame.  Any
of them could have its effect overridden in the
way you suggest.

And there are other approaches, including using
a command that calls `bookmark-jump' passing a
DISPLAY-FUNC argument what the user wants.  That's
much more trivial for a user to do than fiddling
with `display-buffer-alist' to accomplish the same
thing.

None of this seems to me to be an argument against
`pop-up-frames'.  Nor does it seem to be an argument
against having more than one bookmark-jump command,
for a different display behaviors.

See Eli's message today for reasons for the latter.
More generally, see his msg for general arguments
in favor of not promoting user customization of
`display-buffer-alist' as the starting point for
adjusting specific buffer display, especially
command-specific actions.

His arguments are mine too in this regard.

And I add user conveniences such as `pop-up-frames'
and `special-display-*' options to things that we
should promote, not discourage, as user starting
points for getting some specific buffer display
and window selection behavior.

`display-buffer-alist' is great to have.  But
specific this-window, other-window, and other-frame
commands, as well as options such as `pop-up-frames'
and `special-display-*', are better starting points
for most users.

I don't object to `display-buffer-alist'.
I object to promoting its use to the exclusion of
other, simpler ways of doing some of what it does.
I object to _immediately_ throwing users down that
rabbit hole.

I recognize that `display-buffer' is a complex
subject, and its complete and correct doc is
bound to be somewhat hard to grasp.  I don't
have a problem with the doc being complete and
correct - au contraire.

What I object to is having the doc end up being
_only_ that, or even pushing users to that as
the starting point.  As Eli said tactfully,
`display-buffer-alist' should not be the _first
resort_.  Emacs provides some simpler ways to
do some of what it offers, and those are better
starting points, in general.