Re: Pretest begins end-June

[martin rudalics]

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

It's a bit like having the cake and eating it too.

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

Agreed.

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

I'm not 100% sure whether this could lead to difficulties (IIUC I would
have to hardcode the Emacs 23 default values of `split-height-threshold'
and `pop-up-windows' in `display-buffer') but let's agree.

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

Not really.

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

Suppose a user has set `split-height-threshold' to some value for use in
Emacs 23 and in Emacs 24 wants to use a new functionality of
`display-buffer-alist' say apply `fit-window-to-buffer' for adjusting
the window height.  What shall `display-buffer' do?  Respect the value
of `split-height-threshold'?  Adjust the height of the window?  Do both?

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

I think I won't have great problems providing an acceptable heuristic
for `pop-up-frames'.  But I'm afraid that packages outside Emacs have
some very unknown cases in store for me.

martin