Re: display-buffer-alist simplifications

[Stefan Monnier]

> At which point you can give up the idea of merging.  I meanwhile know
> that no one here likes the idea of merging specifiers and don't have the
> slightest intention to fight for it any more.  But no one so far has
> cared to explain how to support all the things people have piled up over
> the years like split-height-threshold, even-window-heights, or
> display-buffer-mark-dedicated.  I'd be all in favor of functions if you
> told me how to write a function that within a year has not been
> rewritten completely because it's oh so important to add a little thingy
> here and there.

I think these will have to be handled in each display-buffer-<foo> function.
Of course, that means that to avoid code duplication we'll want to
structure those functions with care.

>>>> (I'll use the word "macro" for now, but we might want to pick another
>>>> word since "macro" can be confused with keyboard macros.)
>>> I'd very much appreciate if someone could invent a more useful term for
>>> these.
>> The name exists already, it's called a function definition.  It's really
>> well supported by a lot of Emacs code: you can document those "macros"
>> in a very simple way, let users get that doc via C-h f, see them work
>> step by step with edebug, have feedback about their correctness/style
>> with M-x byte-compile-file, ...
> We currently have many ways to specify a function for displaying a
> buffer: `display-buffer-function', `special-display-function',
> `pop-up-frame-function', `split-window-preferred-function', the function
> one can specify via `special-display-regexps'.  I know of two people who
> customized the latter - Drew and you.  This doesn't strike me as a story
> of success.

Irrelevant.  I'm not talking about the success of hooks, I'm talking
about the success of functions as a way to name a bunch of things, so you
can reuse them conveniently.
I don't really care if people define their own functions or not: we'll
provide our own set of functions so those who can't define their own can
just chose one of the predefined behaviors.
The hook just provides a good way to structure and modularize the code.

>>>> - `display-buffer-alist' is an alist that maps a matcher (regexp,
>>>> label, or matcher function) to an alist of display specifiers.
>> If display specifiers are of the form (VAR . VAL), then you presumably
>> mean "a list of display specifiers" rather than "an alist of ...".
> It's an alist where the key of each element is a display specifier.

I'm lost.
So display-buffer-alist would be a list of (MATCHER . THINGS) where
THINGS are lists of (DISPLAY-SPECIFIERS . SOMETHING-ELSE)?  What are the
SOMETHING-ELSE and what do they do?

> OK.  I agree with the idea to support the old code and its options as
> fallback and try to get a new behavior.  But what I'm missing is a
> strategy for how to merge-in the re-bindings of the old options within
> the old _and_ the new code.  Things like

> (defun message-mail-other-window (&optional to subject)
>   "Like `message-mail' command, but display mail buffer in another window."
>   (interactive)
>   (unless (message-mail-user-agent)
>     (let ((pop-up-windows t)
>         (special-display-buffer-names nil)
>         (special-display-regexps nil)
>         (same-window-buffer-names nil)
>         (same-window-regexps nil))
>       (message-pop-to-buffer (message-buffer-name "mail" to))))

> which I intended to rewrite as

> (defun message-mail-other-window (&optional to subject)
>   "Like `message-mail' command, but display mail buffer in another window."
>   (interactive)
>   (unless (message-mail-user-agent)
>     (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window)))

Rather than `other-window', my suggestion is to pass a RULE,
i.e. something like '(display-buffer-other-window . ARGS), but yes that
sounds about right.

> would then become

> (defun message-mail-other-window (&optional to subject)
>   "Like `message-mail' command, but display mail buffer in another window."
>   (interactive)
>   (unless (message-mail-user-agent)
>     (let ((pop-up-windows t)
>         (special-display-buffer-names nil)
>         (special-display-regexps nil)
>         (same-window-buffer-names nil)
>         (same-window-regexps nil))
>       (message-pop-to-buffer (message-buffer-name "mail" to) 'other-window)))

No, because the RULE takes precedence over the
display-buffer-default-rule which is the one that obeys pop-up-frames
and stuff.  At least, that's what my idealized design does.
Of course, such paper designs tend to behave unrealistically well.

>> So, as is the case now, your list of specifiers is not truly an alist
>> (i.e. earlier elements don't override later elements), instead it's
>> a mix between an alist and an `or block'?
>> That sounds like a problem.
> If someone told me how to address the problem of merging specifiers in a
> different way I'd be all ears.

My suggestion is to not merge them, basically.


        Stefan