Re: display-buffer-alist simplifications

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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'd make a "display method" be a function, i.e. one of
`display-buffer-reuse-window', `display-buffer-pop-up-window', ...
At which point you can get rid of the idea of a "macro specifier" since
function definitions work just as well.

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

The name exists already, it's called a function definition.  It's really
well supported by a lot of Emacs code: you can document those "macros"
in a very simple way, let users get that doc via C-h f, see them work
step by step with edebug, have feedback about their correctness/style
with M-x byte-compile-file, ...

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

If display specifiers are of the form (VAR . VAL), then you presumably
mean "a list of display specifiers" rather than "an alist of ...".

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

I hope by now you all know what I think of "macro specifiers".

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

I think that, as much as possible, the old options should only be used
by the old code.  Trying to translate them into the new framework is
generally a bad idea.  Especially if it may end up influencing the end
design: let's first design something clean and flexible regardless of
details of the old behavior.  Then figure out how to provide backward
compatibility, without impacting the design.

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

So, as is the case now, your list of specifiers is not truly an alist
(i.e. earlier elements don't override later elements), instead it's
a mix between an alist and an `or block'?
That sounds like a problem.


        Stefan