Re: display-buffer-alist simplifications

[martin rudalics]

> One difference is that frame parameters don't interact with one another.
> Each entry in default-frame-alist overrides any corresponding entry in
> initial-frame-alist, and is overridden in turn by any corresponding
> entry in window-system-default-frame-alist.

With Emacs 23 `pop-up-frame-alist' overrides `default-frame-alist' and
`special-display-frame-alist' overrides `pop-up-frame-alist', hence you
may have to know the values of five lists to know what really goes on
when popping up frames (disregarding `frame-inherited-parameters' which
are applied after the frame has been created).

These parameters interact like the specifiers of `display-buffer-alist'
with one fundamental difference: The normalization procedure for frame
parameters removes all instances of overriden parameters.  It can do so
because frame creation is guaranteed to succeed in the first attempt or
fail forever.

The normalization procedure for `display-buffer-alist' doesn't remove
instances of overridden parameters because processing one method
specifier may fail in which case the next method specifier has to be
tried.

> Another difference is that in default-frame-alist, each stored value
> (i.e. the cdrs of an alist entry) has a straightforward meaning: it is a
> value of a frame parameter.  In display-buffer-alist, each stored value
> is a _list_ of specifiers, and each specifier has its own no-obvious
> meaning.  For example, in the specifier
>
>    (reuse-window nil nil nil)
>
> each of the `nil's means something different, and you have to look up to
> docstring to figure out what it is.

That's true.  Just as I never got around remembering the order of edges
returned by `window-edges'.

martin