Re: display-buffer-alist simplifications

[Juri Linkov]

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

Very good for backward-compatibility.

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

I meant "user-specific behavior can override the _default_ and
function-specific behavior", i.e. I forgot to mention that
users can override the default behavior as well.  If now the default
behavior is based on the users old settings, then users new settings
should override them.  For instance, when old customization in .emacs
sets `pop-up-frames' to t, and the user customizes `display-buffer-alist'
to not create a frame, then settings from `display-buffer-alist'
should override the old settings `pop-up-frames'.

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

My concern is how users will be able to override parts of the
default behavior?  For instance, how users can specify a rule
to override the default and to not to balance/even window sizes?
I understand that using settings like (reuse-window-even-sizes . nil)
and (reuse-window-even-sizes . t).

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

How easy is to add new macros like `near-minibuffer' and `below-selected'?
Can users add own macros?

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

I'm sure that most authors will be lazy or forget to add labels.
And how users are supposed to deal with the lack of labels?
Should they send mails to the authors asking them to add labels?
Honestly, I think adding labels was good intention but they are useless.

For some exceptional cases where it's impossible to override the
function-specific behavior based on `buffer-or-name' or `this-command',
then a label could be specified as part of specifiers like
`((label . "info-other-window") ...)'.

Or maybe we can't remove the 3rd argument of `display-buffer'
for backward-compatibility with the old version that had 3 arguments,
so we should keep the 3rd argument and use it for something?