Re: display-buffer-alist simplifications

[martin rudalics]

> There are three levels where the window displaying behavior can be defined:
>
> 1. default behavior with good heuristics.  It can be either hard-coded

It currently is hard-coded with the precise behavior specified by the
user's settings for the Emacs 23 options and the default fallbacks of
Emacs 23 `display-buffer'.

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

The latter function in fact initializes `display-buffer-alist' from the
users old settings, the Emacs 23 default if emacs -Q is used.

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

Not really.  I assume that most `display-buffer' calls do not set the
specifiers argument.  User-specific behavior can be mainly seen as what
customizing buffer display options does in Emacs 23.  If and only if
users are dissatisfied with the specifiers argument they override it.

>    But I think it should be separate from the definition of the
>    default behavior and should not be merged with it.

If a user doesn't care about specifying an option, the default behavior
will be merged in.  How would you avoid that?

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

There are only two major groups: The pop-up-windows group and the
pop-up-frames group.  Reusing windows is part of both (and of the
single-frame-single-window minority).

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

Basically, that's what macro specifiers are intended for.

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

I consider labels as something to quickly override the behavior for a
specific function invocation until a better solution has been found.

martin