Re: display-buffer-alist simplifications

[Stefan Monnier]

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

Here are the difference I see:
- use functions rather than a finite set of symbols.
- handle the FUNCTION or FUNCTIONS (i.e. the list of methods to use/try)
  separately from the other arguments, i.e. separate the part which is
  tried in sequence from the part that's handled as an alist.

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

Yes (unless message-mail-other-window keeps using the old let-binding
horror, of course).


        Stefan