Re: display-buffer-alist simplifications

[Stefan Monnier]

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

We can combine them with a "a\\|b\\|c" regexp.

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

I don't even know why you added the `label' case, so I don't think we
should worry about adding more types.

More generally, I have the impression it's a bit overengineered.
I can't find any comment anywhere that explains/justifies
the complexity.  Could you explain it here to help us refine the design
(or to add the explanation to the code)?

AFAIK, the only feature I know to be needed compared to what was
provided in Emacs-23 is a parameter `where' to display-buffer which
generalizes the `same-frame' parameter by turning it into a value of the
`where' and allowing other values such as `same-window' or
`near-minibuffer'.


        Stefan