Re: display-buffer-alist simplifications

[Stefan Monnier]

>> We should keep the old mess in 2 for backward-compatibility
>> and design a new clean and simply way to specify 3 and 4, so
>> we don't need to merge new specifiers with old user settings in 2,
>> because new specifiers just override the old user settings.
> With the scheme sketched above users have no chance to specify what they
> want when they want to use the new design _and_ respect the application
> specifiers.  When they set the new specifiers they would override the
> application.

Yes, and I think that's fine.  We may want to provide a 5th level for
elisp code that lets it override user settings.  This could then be used
for things like C-x 4 and C-x 5 which are ways for the user to say
"please override my own settings".

For the `not-this-window' behavior, I'm still not sure how best to
do it.  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.

>> 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 or for users who set
display-buffer-alist.


        Stefan