Re: display-buffer-alist simplifications

[martin rudalics]

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

What the doc-string of `display-buffer-alist' individually describes for
each specifier.  For the reuse-window specifier it's a <window, buffer,
frame> triple, for the pop-up-window specifier it's a list of <window,
side> tuples, and for many other specifiers it's a boolean.

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

I'm lost here.  Do you mean that users who prefer the old
`display-buffer' behavior get overridden by the application whenever it
passes an argument but do get the old behavior when the application does
not pass an argument?

martin