Re: display-buffer-alist simplifications

[Juri Linkov]

> At which point you can give up the idea of merging.  I meanwhile know
> that no one here likes the idea of merging specifiers and don't have the
> slightest intention to fight for it any more.  But no one so far has
> cared to explain how to support all the things people have piled up over
> the years like split-height-threshold, even-window-heights, or
> display-buffer-mark-dedicated.

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.

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