[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: display-buffer-alist simplifications

From: Andy Moreton
Subject: Re: display-buffer-alist simplifications
Date: Tue, 02 Aug 2011 00:34:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (windows-nt)

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]