Re: Pretest begins end-June

[Stefan Monnier]

>>> (let ((pop-up-frames t))
>>> (pop-to-buffer buffer))
>> 
>> The part I don't understand is why we can't preserve backward
>> compatibility for such code.

> Because it's not quite easy to decide in general which value should
> prevail.  When `display-buffer' encounters a setting like this it would
> have to know whether it comes from a user who has set this in .emacs for
> Emacs < 24 or from an application that has not yet adopted the new
> behavior.

Let me put the question differently:
*how* can we support code that rebinds pop-up-frames?

I think preserving backward compatibility for this case is important,
because it is used in many packages, not all of which are included in
Emacs.

> In the former case, I would have to merge the request to pop up a new
> frame with the actual customization of `display-buffer-alist'.  Now
> `pop-up-frames' is probably not very problematic in this context, but
> the options for popping up and reusing windows have been expanded
> considerably and most of these would get lost.  Note: They would get
> lost because `display-buffer' would _have to assume_ that a specific
> behavior was requested by the application although that application did
> _not_ rebind the corresponding variable in the first place.

IIUC, the problems are:
1- detect that pop-up-frames was set.
2- decide whether pop-up-frames was set by user or let-bound by the caller.
3- for each of those two cases, take this request into account.
4- same for pop-up-windows.

Case 1 is easy (set the default value to `unset' and you're done).
Case 2 is more difficult.  Of course, we could add a new primitive that
walks the specpdl stack to decide if a var is let-bound or not, but that
doesn't sound very appealing.
Case 3 doesn't sound too hard; IIUC it involves losing some
functionality but that functionality is absent from Emacs-23 anyway.
Do we really need to solve case 2?  Probably not.

> It might be possible to use some heuristics like "`pop-up-windows' is by
> default t, so if `display-buffer' sees that this is t it will disregard
> it and consult the value of `display-buffer-alist' instead".  But doing
> such guesses doesn't strike me as very robust :-(

If we declare pop-up-frames and pop-up-windows as obsolete, I think it's
OK to have an heuristic simulation of its semantics as long as it
handles the known cases well enough.


        Stefan