Re: display-buffer-alist simplifications

[Juri Linkov]

> I'm lost here.  Do you mean that users who prefer the old
> `display-buffer' behavior get overridden by the application whenever it
> passes an argument but do get the old behavior when the application does
> not pass an argument?

Maybe in precedence levels instead of

1. default global behavior
2. old user settings (pop-up-windows etc)
3. new display-buffer's arg
4. new user settings (display-buffer-alist)

we should consider

1. default global behavior
2. new display-buffer's arg
3. old user settings (pop-up-windows etc)
4. new user settings (display-buffer-alist)

It provides more backward-compatibility.

A command like `message-mail-other-window' are a special case.
When by its definition a command have to override user settings
then it could use a special specifier like:

  (message-pop-to-buffer (message-buffer-name "mail" to)
                         '(display-buffer-other-window (important . t)))

This is like `!important' in CSS gives priority to some specifications.
>From http://www.w3.org/TR/CSS2/cascade.html#important-rules :

  CSS attempts to create a balance of power between author and user
  style sheets.  By default, rules in an author's style sheet
  override those in a user's style sheet.  However, for balance,
  an "!important" declaration takes precedence over a normal declaration.
  Both author and user style sheets may contain "!important" declarations,
  and user "!important" rules override author "!important" rules.

BTW: according to the terminology used in CSS, a RULE consists of
a SELECTOR (a list of conditions matching different contexts),
followed by a DECLARATION BLOCK that consists of a PROPERTY NAME,
followed by a PROPERTY VALUE.

Perhaps the term DECLARATION BLOCK is not better than our current
DISPLAY-SPECIFIERS that consists of DISPLAY-FUNCTION(S) and DISPLAY-ALIST.