Re: display-buffer-alist simplifications

[Juri Linkov]

> Since XEmacs specifiers are *not* used to configure buffer to window
> mapping, I can't promise that Martin's design will be as successful in
> this application, but I think it's very much worth a try.

GNU Emacs has a similar system of specifiers in face definitions.
It's simpler but still powerful enough for its purpose.
`defface' defines a set of conditions for different contexts depending
on a list of such specifiers as `type', `class', `min-colors',
`supports' that maps to a set of merging face attributes.

The advantage of Martin's design is that it provides a similar set of
conditions ("buffer identifiers") that can be easily extended.
Currently `name' and `regexp' match the name of the buffer to display.
But it would be useful to add more identifiers such as e.g.
"from-name" and "from-regexp" to match the name of the original
buffer from which a new buffer should be displayed, so a rule like
'(((from-name . "*Help*")) ((reuse-window nil same))) will reuse
the selected window to display any buffer (regardless of its name)
if the selected window's buffer was "*Help*". This is easy to do
with Martin's design.

Generally behavior is defined by a set of rules with two parts:
conditions (that define the context) and actions (that define what to do).
In rules defined by `display-buffer-alist' "buffer identifiers" are
conditions and "display specifiers" are actions.  But one problem with
the new design is that some conditions are implicit and hard-coded into
actions.  I mean such conditions that can be expressed as e.g.
"the buffer is already displayed in another window or frame",
"the selected window is to narrow to split" and other restrictions
depending on the values of `window-min-width', `window-min-height', etc.

Defining such conditions explicitly will allow writing more precise rules
and avoid the problem of merging actions (they will be executed
sequentially without problems).

Another difference between face specifications and window displaying
is that rules that define how to display faces are grouped and named
by `defface' and can grouped further into themes.  Another important
feature of face specifications is the attribute `:inherit' that
allows creating new definitions based on existing definitions.
That's why faces are easy for users to customize.  Doing something like
that for windows will help to improve usability of the new design.