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

[Drew Adams]

>  > (Non-nil is not the same as non-t, BTW, for both 
>  > `pop-up-frames' and the NOT-THIS-WINDOW arg of `display-buffer'.
>  > If you were speaking about that arg, then any non-nil value
>  > has always had the same behavior as a value of t...)
> 
> This is no more the case.  That argument is called SPECIFIERS now and
> certain values (like lists and certain symbols) will be reserved for a
> different behavior.  If you don't like such a change, you will have to
> talk to someone else; I already mentioned Juri and Stefan as potential
> addressees.
> 
> Meanwhile I can offer the below substitute for
> `display-buffer-normalize-specifiers-1' which should address most of
> your concerns in this area.

1. The text you quoted from me was only a parenthetical remark -- see the "BTW",
plus the parens.  I hope that your reply to it does not constitute your complete
response to this bug report.  The bug is described clearly, outside of and
independent of that remark.

2. Anyway, I tried your proposed redefinition of
`display-buffer-normalize-specifiers-1', just in case, and it does not have any
effect on this bug.  See below: the `other-window' value is not something
special in my code, and the fix is certainly not to treat that particular symbol
as a special case.

3. If users must change all of their existing calls of the form
(display-buffer buf 'SOMETHING-NON-NIL), to keep the same behavior as before,
then you need to explicitly say so - in the doc.  I don't mind doing that,
personally, but I need to know just what the correct change is.  Other users are
in the same boat.

FWIW, the only reason I have sometimes used a value such as a symbol
`other-window' or `OTHER-WIN' instead of `t' in cases like this is to make the
code a little more readable - it's just a reminder of what a non-nil arg does
here.  So there is nothing special in my use of `other-window' as the value, and
I don't have any problem with changing such non-nil values to something else (to
`t'?).

4. But is that really necessary, for you to make the changes that you need?
That's for you to answer, but here are some thoughts that I hope will help.

Wrt the general question of changing parameter values such as this one, i.e.,
defining new, specific non-nil values where previously all non-nil values were
treated the same:

The usual approach, and a better one in general, is to allow for the new
treatment of specific non-nil values, but to still treat any other non-nil value
the same as before.  IOW, a priori I'm not wild about your _design_ choice of
changing the meaning of arbitrary (non-specific) values.  Why not just handle
the specific values you want/need to handle, and let any other non-nil value do
what it has always done?

5. In the case of `display-buffer', I can see that you want to handle a _list_
of SPECIFIERS, but why also introduce the "convenience" of also handling
arbitrary non-list values as specifiers?  Why not just interpret a list as
SPECIFIERS?  That would certainly break less code, since the most common non-nil
values in use are probably symbols.

6. A more important question would be why not, instead of completely changing
the meaning of the second parameter, add a new (optional) parameter for your
SPECIFIERS needs?  I know you said that Juri suggested to reuse the second
parameter (NOT-THIS-WINDOW) for this, but that doesn't seem like such a great
idea.  That's not reuse; it's just a recipe for breaking code.

7. Anyway, this ("any non-nil value has always had the same behavior as a value
of t") is just a side discussion wrt the bug reported.  Please do not lose sight
of the bug itself, whatever you decide about this side issue.

It is particularly important that you understand, as you apparently did not when
you designed this change, that non-nil `pop-up-frames' makes all
`*-other-window' functions use another frame, not another window.  It is an
important Emacs feature that it is enough that a user customize `pop-up-frames'
to non-nil, to make all other-window commands (e.g. `C-x 4' prefix) behave as
other-frame commands (`C-x 5' prefix).

Please DTRT.  Thx.