Re: display-buffer-alist simplifications

[martin rudalics]

> Currently the following layers are planned:
>
> 1. default global behavior
> 2. old user settings
> 3. application specifiers
> 4. new user specifiers
>
> 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.

>> would then become
>>
>> (defun message-mail-other-window (&optional to subject)
>>   "Like `message-mail' command, but display mail buffer in another window."
>>   (interactive)
>>   (unless (message-mail-user-agent)
>>     (let ((pop-up-windows t)
>>          (special-display-buffer-names nil)
>>          (special-display-regexps nil)
>>          (same-window-buffer-names nil)
>>          (same-window-regexps nil))
>>       (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window)))
>>
>> for approximately as long as how we are supporting the old code.
>
> 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'.

martin