Re: display-buffer-alist simplifications

[martin rudalics]

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

I suppose that what you mean here is to rewrite Emacs 23 options like
`even-window-heights' and `split-height-threshold' where applicable.
These values would serve as the default values for any buffer, that is,
there would be no distinction between *Help* and *Info* buffers wrt the
minimum height of their windows, I presume.  Then the applications could
override this by their plists and `display-buffer-alist' would override
the application's and the default values.  Is that correct?

One idea of `display-buffer-alist' was to concentrate all display buffer
related variables into one and make any additions inside that variable.
A basic drawback of the <= Emacs 23 approach was that we always added
variables like `display-buffer-reuse-frames' and
`display-buffer-mark-dedicated' with very ad hoc semantics many people
don't understand.  (Maybe I exaggerate here but at least I don't
understand them as recent problems with reusing frames and marking
reused windows as dedicated shows.)

Personally, I hardly ever had problems with displaying buffers because I
don't do that often.  So if people agree that exposing these variables
is TRT I can principally do that.  For this purpose we'd first have to
go through each of these variables and decide

(1) on a suitbale name (and possibly any aliases), and

(2) whether and what should be changed in the possible values and how to
    represent them.

Finally we'd have to decide what to do about options that don't exist
yet like `pop-up-window-set-height'.

What I probably cannot do is incorporating buffer specific options like
`special-display-regexps' into this scheme.  These apply individually to
buffers and do require the merge-in behavior of things like
`even-window-heights' you probably want to avoid by exposing the
internal variables.  I'm obviously all ears for any suggestions how to
do that.  (If there are any doubts about why these are problems recall
that `display-buffer-alist' is nothing else but a generalization of
`special-display-regexps' and `special-display-buffer-names'.)

> 2) Make the "display methods" specifier just another one of these
>    variables, e.g. call it `display-buffer-method'.

Would this discriminate buffers via regexps and how would you apply the
"try reusing a window and if that fails pop up a new one ..." here?  I
assume you'll say "no" to both of them.

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

Could you give an example of how to specify reusing a window along these
lines?  And of how to specify the above mentioned "try reusing a window
and if that fails pop up a new one ..."?

Would we write, for example,

  (setq display-buffer-method '(pop-up-window reuse-window))

If so how would we express to first find another window showing the same
buffer and then another window showing another buffer?

martin