Re: display-buffer-alist simplifications

[Stefan Monnier]

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

All the old user settings should be obeyed by the "default global
behavior" because that should use the old code.  We may want to let some
of the old user settings affect the new display commands, but that would
be done in an ad-hoc way.

So we have

1. display-buffer-default-action (whose default value calls the old
   code which obeys old user settings).
2. display-buffer's arg.
3. display-buffer-alist.

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

I think that the best way to handle `info-other-window' and the
"C-x 5 prefix command" is to introduce a fourth level:

4. display-buffer-override-action.

which can be let-bound in info-other-window and temporarily set during
the execution of the next command in a hypothetical C-x 5 prefix command.


        Stefan