Re: display-buffer-alist simplifications

[martin rudalics]

> My current idea is to redefine RULEs from (FUNCTION . ARGS) to
> (FUNCTION . ALIST), and then FUNCTION called is the one from the highest
> precedence, and the ALIST passed to it is the concatenation of all the
> ALISTs (the one from display-buffer-default-rule, plus the one from the
> caller, plus the one from display-buffer-alist, plus the one from
> display-buffer-override-rule), and `not-this-window' would be one of the
> possible ALIST keys.  So if it's provided by the caller it will appear
> as arg to FUNCTION, unless it's explicitly overridden by
> a (not-this-window . nil) element in the display-buffer-alist.

I begin to wonder how this differs from the current handling of
`display-buffer-alist'.

>>> Why wouldn't `display-buffer' prefer new settings in the `SPECIFIERS' arg
>>> over the old settings in `same-window-regexps' etc.?  IOW, when the
>>> `SPECIFIERS' arg is `other-window' then `display-buffer' should ignore
>>> the values of `same-window-regexps' etc.
>> Because this would change the behavior of `display-buffer' for users who
>> prefer good ol' `display-buffer'.
>
> It should only change the behavior for calls to display-buffer which use
> the new RULE/SPECIFIER parameter

So when an application sets the argument, people who want the old
behavior are overridden.  This means that such people can use
`message-mail' as before but any of their customizations affecting
`message-mail-other-window' or `message-mail-other-frame' are lost.

> or for users who set
> display-buffer-alist.

martin