bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames'

[Drew Adams]

>  >> I can't find the idiom (if pop-up-frames in the current trunk
>  >> so I would first like to know why and how it is used.
>  >
>  > How about looking at the Emacs sources before you made 
>  > your changes? ;-)

Re-reading that now, I see that it could be misinterpreted.  I meant that even
if you find no such tests in the current Emacs code (i.e., after your changes,
which would be understandable, since you have probably removed them), there are
such occurrences in the Emacs code prior to your changes - i.e. Emacs 23.3, and
even in a build from two weeks ago.

You said that you found no occurrences of (if pop-up-frames...) in the source
code.  My point is that there are plenty of occurrences of nil/non-nil tests of
`pop-up-frames' in the Emacs 23/22/21/20/... source code.  grep for
`pop-up-frames', not just for "(if pop-up-frames".

>  > If you grep the Emacs 20, 21, 22, or 23 Lisp source code for 
>  > `pop-up-frames' you will see lots of hits, some of which are
>  > tests of its value.  For example (Emacs 23.3):
>  > From help.el: (cond ((or pop-up-frames...)...)
> 
> All these tests will be removed/replaced in due time because these
> variables are obsolete now.

No doubt.  The question was about what to replace such tests with.

I would even expect (like to see) an entry in etc/NEWS that addresses this
specifically.  It is typical when some construct becomes unrecommended or
deprecated to provide specific info about just what to use in its stead.  What
is the recommended replacement for a nil/non-nil test of `pop-up-frames'?

>  > I use such tests in only a couple of places.  They are of 
>  > course based on the (original) meaning of `pop-up-frames':
>  > non-nil means `display-buffer' uses a separate frame.
> 
> And that was incorrect already in Emacs 23.  The value 'graphic-only
> should have been dealt with separately.

Not if the code in question involves only graphic displays.

In any case, that is irrelevant to my concern.  Think Emacs 22 (or 21 or 20 or
19 or 18), if you prefer.  My code in a couple of places, and the Emacs 22
source code in many places, effects a nil/non-nil test of `pop-up-frames'.  What
is the proper replacement for that, i.e., to get the same behavior?

>  > Nothing special.  So the question is how to test that user
>  > intention using the latest Emacs design.  From my code:
>  >
>  > ;; If non-nil `pop-up-frames' then inhibit showing annotation.
>  > (let ((bookmark-automatically-show-annotations
>  >        (and bookmark-automatically-show-annotations
>  >             (not pop-up-frames))))
>  >
>  > ;; Use separate frames instead of windows if `pop-up-frames'
>  > ;; is non-nil or if prefix arg is negative.
>  > (cond (...)
>  >       ((or pop-up-frames option)
>  >        (while file-list (find-file-other-frame...
> 
> Code shouldn't try to guess the user's intentions in the first place:

Huh?  What is that about?  `pop-up-frames' is a user option.  What's to guess
about it?

How about forgetting for a moment what you think code should and shouldn't do,
and just let us know what the replacement for a nil/non-nil test of
`pop-up-frames' is?

> The strategy, in increasing priority, is
> 
> - users express their intentions in `display-buffer-alist',

What is the Emacs 24 equivalent to the intention expressed by - and the behavior
realized by, a nil/non-nil `pop-up-frames' test prior to Emacs 24 (i.e. prior to
the introduction of your feature)?

Can you express that behavior in terms of `display-buffer-alist'?  If so,
presumably you can give us the test of the `display-buffer-alist' value to use
in place of the nil/non-nil test of the `pop-up-frames' value, that is, a test
that gives the same behavior.

That's all I'm asking for here: how to do, using your new constructs, what we
have always done before using `pop-up-frames'.

> - the code can suggest a better solution by passing a second 
>   argument to the buffer display function,
> 
> - users can override the code by setting the override specifier in
>   `display-buffer-alist'.

That's all too vague for me, I'm afraid.  What is the answer to the question?
How to reproduce (e.g. by testing `display-buffer-alist') the same behavior that
testing `pop-up-frames' as a nil/non-nil value gave before?

> Code should only express suggestions in the sense that "displaying the
> buffer in this or that way is best to my knowledge".  The user can
> accept that suggestion or override it.  In most cases, however, code
> should not suggest anything and leave the decision to the user.

Please stop with the "should"s regarding programming style etc. - that's not
very helpful.  Emacs code has always bound some user variables.  There is
nothing special or sacrosanct about `pop-up-frames' in this regard.  Take a look
at the many bindings of `case-fold-search'...

In general, user settings "should" prevail, but there are cases where it can
make sense for code to override the user's preferred default behavior
(customization), including by binding a user option.  Whether or not a _given_
binding is appropriate is another matter.  But the blanket idea that code
"should not" bind user options is a non-starter, at least for me.

We can certainly agree to disagree about this.

But I will suggest that your point of view on it seems quite rigid, and it is
unsupported by historical experience - within either the Emacs sources or
third-party code.  Recognize that no one is saying that your code "should" bind
any given option.  It is you who is apparently declaring that _all_ code must
_never_ bind _any_ user option.  That is a quite rigid/doctrinaire view, no?

> Obviously, if your code is targeted only at users not customizing
> `display-buffer-alist', you can test `pop-up-frames' as before,

I'm perfectly willing and wanting to have my code support whatever is the new
design.  That's why I'm asking the question!

It does not matter in the end whether I think the new design is better or worse
than before, or better or worse than some possible alternative, or even whether
I understand it.  In any case, I want/need to support it in my code.  I'm not
redesigning Emacs here - you are.  I'm just trying to adapt my code to your
changes.

What I'm asking is how to do so.  My code needs to support multiple Emacs
versions, and I would like it to DTRT for Emacs 24, which I gather means testing
`display-buffer-alist' appropriately.  The question is how to use/test that
variable to get the same behavior as before, i.e., the same behavior as for
other Emacs versions.  Why is this such a hard question for you to address?

> taking care of the special values 'unset (which means the user 
> doesn't bother) and 'graphic-only.

Please tell me specifically what you mean - I don't follow.  Please take a given
nil/non-nil test of `pop-up-frames' and let me know what it would be for Emacs
24 and `display-buffer-alist' instead.

Preferably, translate Emacs 22's (if pop-up-frames...) to code that will do the
same thing in _both_ Emacs 22 and Emacs 24 - e.g., using `display-buffer-alist'
for the latter (i.e., when `boundp').  Thx.