Re: display-buffer-alist simplifications

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> You can already do that since Emacs-20 by setting special-display-regexp
>> to something like
>> (add-to-list 'special-display-regexps
>> '("\\*Completions\\*" my-display-completions))
>> Tho I haven't seen any sample "my-display-completions" yet.
> A possible explanation is that users don't like to write functions
> to specify buffer-displaying behavior :)

Most likely, especially functions such as the my-display-completions you
described, which is pretty difficult to write.

>>> 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?
> Selecting from the set of predefined values is easier than
> writing a new function to customize the buffer-displaying behavior.

My proposal to only use FUNCTION in the API does not mean we wouldn't
provide a choice of alternatives in the Custom UI.  I fully intend to
have the same kind of "select behavior from a set of predefined values"
as we have now.  It's just that the values you choose are functions, so
while the :tag may say "same frame" the value will be the
`display-buffer-same-frame' function rather than a `same-frame' symbol.
And in the docstring of buffer-display-alist we would include links to
those predefined functions.
And the args to those function would still be your usual ALISTs with
symbols as keys.

>>> 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).
> In classical logic, necessary part of "rule" is "condition".

I don't care about which name is used.  I didn't choose SPECIFIER
because that's already used in this discussion for the same purpose but
with a different representation and the whole point of this discussion
is to figure out which representation to use.

> So "rule" is rather such an element if `display-buffer-alist':
>   ("*Completions*" display-buffer-according-to-specifiers (spec . val))
> But since "condition" part is unnecessary in the call of `display-buffer',
> what remains is just specifiers.

My suggestion was to have display-buffer-alist be a list of (CONDITION
. RULE).  If you don't like those names, then please read my messages
through a transcriptor.  I don't think "RULE" appeared with any other
meaning within this thread, so the transcription is unambiguous.

> According to your earlier proposals such specifiers should be
> as short as possible like:

>   (display-buffer buffer 'same-frame)
>   (display-buffer buffer 'same-window)
>   (display-buffer buffer 'other-window)
>   (display-buffer buffer 'nearby)
>   (display-buffer buffer 'near-minibuffer)
>   (display-buffer buffer 'below-selected)
>   (display-buffer buffer 'side-window)

I don't know if I was worried about size, but right now I'm not too
worried about size, no.

> It will cause the callers to ask the questions like
> why this can't be written simply as:

>   (display-buffer-reuse-window buffer)
>   (display-buffer-pop-up-window buffer)

Easy: so display-buffer-alist may override it.


        Stefan