[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))))
>
> 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
- Re: display-buffer-alist simplifications, Juri Linkov, 2011/08/01
- Re: display-buffer-alist simplifications, Juri Linkov, 2011/08/01
- Re: display-buffer-alist simplifications, Juri Linkov, 2011/08/01
- Re: display-buffer-alist simplifications, Juri Linkov, 2011/08/01
- Re: display-buffer-alist simplifications, Juri Linkov, 2011/08/01
- Re: display-buffer-alist simplifications, Chong Yidong, 2011/08/01
- Re: display-buffer-alist simplifications,
Andy Moreton <=
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/02
- Re: display-buffer-alist simplifications, Stefan Monnier, 2011/08/02
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/03
- Re: display-buffer-alist simplifications, Nix, 2011/08/03
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/03
- Re: display-buffer-alist simplifications, Stefan Monnier, 2011/08/03
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/04
- Re: display-buffer-alist simplifications, Stefan Monnier, 2011/08/04
- Re: display-buffer-alist simplifications, Chong Yidong, 2011/08/03
- Re: display-buffer-alist simplifications, martin rudalics, 2011/08/04