Re: display-buffer-alist simplifications

[martin rudalics]

>  - Instead of allowing the car of each `display-buffer-alist' element to
>    be a _list_ of matchers, let it just be a matcher.  This is
>    semantically cleaner, and more consistent with other facilities in
>    Emacs, e.g. font-lock-keywords.  Any caller desiring multiple
>    matching conditions can just add multiple alist elements.

I currently produce these via `display-buffer-alist-set'.  But Sam
Steingold earlier bemoaned that

> it produces a lot of separate entries like
>  (((name . "*acl-listener*"))
>   fun-with-args
>   (fun-with-args special-display-popup-frame #1#))
>  (((name . "*scheme*"))
>   fun-with-args
>   (fun-with-args special-display-popup-frame #1#))
>  (((name . "*allegro*"))
>   fun-with-args
>   (fun-with-args special-display-popup-frame #1#))
>  (((name . "*cmu*"))
>   fun-with-args
>   (fun-with-args special-display-popup-frame #1#))
>
> I think it would be better to group them together like I do above.

and I think he's right.  So I'd rather keep the list approach here (but
can be easily convinced of the contrary ;-) ).

>  - Instead of buffer matchers that are cons cells like (name . NAME),
>    (regexp . REGEXP), and (label . LABEL), just use strings or symbols.
>    Strings are to be treated as regexps (if an exact match is desired,
>    the caller uses regexp-quote); symbols are treated as label matchers.

Stefan earlier suggested something similar last year.  I can do that
easily but it somehow precludes that we add other string- or symbol-like
types later (not that I can give or even think of an example).  So if
people agree on this, I'll do it.

>  - Some of the display specifiers seem to allow contradictory meanings,
>    e.g.
>
>       (reuse-window same nil other)
>
>    means to reuse the selected window, provided the window is not on the
>    selected frame.  What does this mean?

Hopefully that `display-buffer' can't find a window meeting this
specification.  It's obviously a static case which means it could be
detected at the time the user sets the customization.

>    And what happens if it's
>    impossible for Emacs to meet the requirements of the specifier?  This
>    is not explained in the docstring.

It's not taken.  Like when you specify to use the selected window if it
shows the same buffer and the selected window shows another buffer.  Or
you want to split a window but `display-buffer' can't find one which is
large enough.

>  - I don't like the fact that different specifiers are set up in a way
>    that the meaning of each specifier depends on the presence of other
>    specifiers.  For example, in the spec list
>
>    ((reuse-window same nil nil) (reuse-window-even-sizes . t))
>
>    the second element only has a meaning if the first element is
>    present---they are not independent.

That's an incorrect deduction, probably because the doc-string is
written badly.  If you add

(reuse-window (reuse-window-even-sizes . t))

as last element to `display-buffer-alist' it will apply to all
reuse-window operations that don't override it.

> It would be cleaner to use a
>    plist, like this:
>
>     (reuse-window :window same :reuse-window-even-sizes t)
>
>    where ALL the behaviors are grouped together.

I haven't looked into how to present plists in the customization
interface.  If I find a good way to do it, I'll make that change.

martin