Re: display-buffer-alist simplifications

[Juri Linkov]

>   (setq display-buffer-fallback-alist
>     '("\\*\\(shell\\|unsent mail\\|mail\\|inferior-lisp\\|ielm\\)\\*"
>       (display-buffer-method reuse-window same-frame)
>       (reuse-window-window same)))
>
> Just to be sure we are one the same page, here is how I imagine the
> system would work:
>
>  - "Display specifiers" are cons cells (VAR . VALUE).  For example,
>    (reuse-window-window other) means that when Emacs is trying to reuse
>    a window, it must use a window other than the selected one.
>
>  - `display-buffer-method' is a special display specifier.  Its VALUE is
>    a list of "display-methods", one of `reuse-window', `pop-up-window',
>    etc., or a "macro specifier" (any symbol except the reserved symbols
>    `reuse-window' etc).

Adding `display-buffer-method' in the same common format (VAR . VALUES)
to specify priorities of methods is a nice way to simplify the current
complex merging behavior of `display-buffer-alist'.

>    (I'll use the word "macro" for now, but we might want to pick another
>    word since "macro" can be confused with keyboard macros.)

Why do we need "macro specifiers" at all?  With a well-designed list
of possible specifiers and values for (VAR . VALUE), "macro specifiers"
should be unnecessary.  Another reason to doubt their usefulness is that
they can't help to define such complex specifiers like `near-minibuffer'.

So if the user doesn't like how a hard-coded specifier behaves, then
the user could override its default behavior with other parameters
(VAR . VALUE), and finally when this turns out to be impossible to do,
then write own function and specify it's name in `display-buffer-alist'.

>  - `display-buffer-alist' is an alist that maps a matcher (regexp,
>    label, or matcher function) to an alist of display specifiers.
>
>  - `display-buffer-fallback-alist' is an alist of display specifiers.

Perhaps a better name is `display-buffer-default-alist'.