Re: display-buffer-alist simplifications

[Stefan Monnier]

>> display-buffer-according-to-specifiers which would interpret its
>> parameters in a similar way to what is now done in Martin's
>> buffer-display-alist.

> I expect this eventually will turn `display-buffer-alist' into

>   (("\\*\\(vc-\\)?diff*"
>     display-buffer-according-to-specifiers (spec . val))
>    ("\\*\\(compilation\\|grep\\)\\*"
>     display-buffer-according-to-specifiers (spec . val))
>    ...)

> because predefined spec values are easier to customize.

Easier than what?

>> I know this won't satisfy everyone, but let-binding as is done above has
>> too many problems of its own.  Maybe we could have a new
>> display-buffer-default-rule variable (not a user option) such that
>> display-buffer uses this variable when its RULE arg is nil, so
>> info-other-window could do
>> 
>> (let ((display-buffer-default-rule '(display-buffer-other-window)))
>> (info ...))
> Yes, a single variable would be enough to override the display-buffer's arg
> (maybe a better name would be `display-buffer-specifiers').

In my proposal, these things are called "rule", where RULE has the form
(FUNCTION . ARGS).

>> A related issue: I tend to dislike the *-other-(frame|window) commands
>> and would rather have C-x 4 and C-x 5 as prefix commands that modify the
>> way the subsequent command works.  Not sure how best to get this behavior.
> Then for completeness there should be a key prefix to force displaying the
> buffer in the same window (when the default behavior is to display it
> in another window).

Great minds think alike,


        Stefan