Re: display-buffer-alist simplifications

[Andy Moreton]

On Mon 01 Aug 2011, Chong Yidong wrote:
> Here is one suggestion.
>
> 1) Expose all the internal "variables" currently living inside
>    display-buffer-alist as Lisp variables, e.g. reuse-window-even-sizes
>    and pop-up-window-min-height.
>
> 2) Make the "display methods" specifier just another one of these
>    variables, e.g. call it `display-buffer-method'.
>
> 3) Change display-buffer-alist so that it is just a method of overriding
>    Lisp variables during display-buffer.  That is to say, it is an alist
>    where each element has the form (MATCHER . OVERRIDES).  The first
>    entry with matching MATCHER takes effect; its OVERRIDES is an alist
>    where each element has the form (VAR . VALUE), which says to bind VAR
>    to VALUE.
>
>    MATCHER will include matching the buffer name to a regexp, but we can
>    add more complex conditionals later, e.g. a way to specify that a
>    variable must have a certain value.
>
> In this scheme, there is no interaction between elements of
> display-buffer-alist, and no interaction between specifiers apart from
> the familiar behavior of rebinding Lisp variables.

This is a very important point, ensuring that smaller pieces can be
composed together into larger lists without changing the semantics. It
is much easier to reason about than the curent design.

>  Martin's example would be implemented like the following:
>
>  (setq pop-up-window-min-height 15)
>
>  (setq pop-up-window-choice '((largest) (lru)))
>
>  (setq display-buffer-method '(pop-up-window))
>
>  (setq
>   display-buffer-alist
>   '((((regexp . "\\`\\*Help\\*\\'"))
>      (pop-up-window-set-height . fit-window-to-buffer))
>     (((regexp . "\\`\\*.+\\*\\'"))
>      (pop-up-window-set-height . 20))))
>
> WDYT?

This proposal is much simpler to understand than the current design.
I've followed the discussion here and read the documentation several
times, and I still cannot make any sense of display-buffer-alist.

Point (3) above is important. Processing the alist only as far as the
entry with a matching MATCHER form is easier to reason about. It is also
more compositional: it allows the user to combine working alists of
specifiers together without surprising changes in the semantics of the
constituent pieces.

    AndyM