Re: display-buffer-alist simplifications

[Juri Linkov <juri@jurta.org>]

> martin, who begins feeling to weak to delve into this subject again.

Having only one customizable variable to specify how to display a buffer
is definitely a very good thing.  One problem is that currently it's
too complicated.  I see the following ways to improve this situation.

There are three levels where the window displaying behavior can be defined:

1. default behavior with good heuristics.  It can be either hard-coded or
   defined in a defvar (or even defconst) with the current default value
   of `display-buffer-alist' (or the result of `display-buffer-alist-set').

2. function-specific behavior can be defined by the arguments
   `specifiers' and `label' of `display-buffer' and override
   the default behavior.

3. user-specific behavior can override the function-specific behavior.
   It seems `display-buffer-alist' was intended to define that.
   But I think it should be separate from the definition of the
   default behavior and should not be merged with it.

To help the users to customize the desired behavior we could allow
to group a set of low-level specifiers into "themes".  So e.g.
for users who prefer using frames we could predefine a "frame theme"
with a set of specifiers that affect displaying buffers in frames.

Each group could be marked with a symbolic tag that can be used
by the `specifiers' argument of `display-buffer', e.g.:

  (display-buffer "*Completions*" 'near-minibuffer)

as well as in the user-customizable variable, e.g.:

  '(("*Completions*" below-selected)
     ("*info*" same-window))

And the value `t' could emulate the old behavior of the argument
`not-this-window' in `display-buffer' for backward-compatibility.

As for `labels' I expect very little use of them.  Maybe we should
allow specifying the command name (i.e. the value of `this-command')
in `display-buffer-alist', e.g.:

  '((("*info*" . info-other-window) same-window))