Re: display-buffer-alist simplifications

[martin rudalics]

> IIUC, the intention of same-window-buffer-names is to specify that such
> buffers should appear in the "same" window.  But if the argument to
> display-buffer specifies some other method for displaying the buffer,
> Emacs should obey that argument rather than same-window-buffer-names.
>
> So, this can be handled by
>
>   (setq display-buffer-fallback-alist
>     '("\\*\\(shell\\|unsent mail\\|mail\\|inferior-lisp\\|ielm\\)\\*"
>       (display-buffer-method reuse-window same-frame)
>       (reuse-window-window same)))

Aha ... so the fallback alist must discriminate buffer names (you didn't
tell me so far how it should look like).

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

If we can manage to get this conveniently and consistently it would be a
great improvement.  I already explained to Stefan that I was too silly
to get this part right (IMHO, a term like "reuse-window-window" is very
easy to mistype as "reuse-window").

>  - `display-buffer-method' is a special display specifier.

Good.  I haven't yet explored all possible misuses of this but it makes
it clear that the stuff that follows is a method.  This is, admittedly,
not clear in my design.

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

I'd very much appreciate if someone could invent a more useful term for
these.

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

OK.  I slowly begin to understand what a matcher function could be like.

>  - `display-buffer-fallback-alist' is an alist of display specifiers.

OK.  I don't like the name much (I would rather call the other one
something like `display-buffer-overriding-alist' and the fallback one
`display-buffer-alist' but that's a minor issue).

>  - `display-buffer-macro-specifiers' is an alist that maps a "macro
>    specifier" to an alist of display specifiers.  It must include a
>    `display-buffer-method' specifier.

OK.  We have to invent a mechanism that makes `display-buffer' work even
if someone removes more essential associations from the list.  The
SPECIFIERS argument below should be able to reference it safely.

>  - The action of `display-buffer' can be conceptually described this
>    way:
>
>    1. Construct an alist of display specifiers by appending (in order)
>       (a) the first matching display specifier alist found in
>       `display-buffer-alist', if any
>       (b) the SPECIFIERS argument

... if any ...

>       (c) `display-buffer-fallback-alist'

Good.  Would `display-buffer-fallback-alist' be constructed from the
user's Emacs 23 options, from the Emacs 23 default options, or be nil?

>    2. Get the value of the `display-buffer-macro-specifiers' specifier
>       from this alist.
>
>    3. Iterate through the list of specified methods, trying to display
>       with each method, obeying specifiers such as `reuse-window-window'
>       drawn from the constructed alist.  If the method fails, try the
>       next method in the list.  If it succeeds, stop.
>
>    4. If one of the methods is a macro specifier, add that macro's
>       specifier alist "temporarily" to the front of the constructed
>       alist.  Then look up `display-buffer-macro-specifiers' again, and
>       iterate again through that list, as in step 3.

Here you mean to not expand all macro specifiers at call time but lazily
when needed.

>       The "macro" fails
>       iff all of its `display-buffer-macro-specifiers' fail.

OK.

I'm still not sure where the `even-window-heights' stuff would go
though.  IIUC it must be by default present in each and every macro
specifier that reuses any window but the selected one.  Same for the
minimum height/width specifiers.

martin