Re: display-buffer-alist simplifications

[Eli Zaretskii <eliz@gnu.org>]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Tue, 26 Jul 2011 22:43:20 -0400
> Cc: emacs-devel@gnu.org
> 
>   (display-buffer buf
>     '((reuse-window :buffer same :window other)
>       (pop-up-window :root lru :side right :min-width 10)))
> 
> This syntax is (IMO) much more readable.  It is easy to guess what every
> element means---one problem I have with the current design is that I
> have to delve into the docstring to work out what the different elements
> and special tags mean.  And it has the advantage of similarity with
> other facilities in Emacs, like defface specs.

OTOH, we have the example of frame parameters alist, which supports
merging with the default-frame-alist, is quite self-explanatory, and
works quite well in practice, AFAIK.

So why wouldn't display-buffer-alist be useful as an alist as well,
without any need for a plist?

> My inclination would be to keep the display specifier argument to
> `display-buffer', switching to the plist syntax, but leave out
> `display-buffer-alist' until we can work out a better way to do merging
> (e.g. in 24.2).

If there's no display-buffer-alist, then how can users customize the
behavior to their liking?  The current code sets up
display-buffer-alist from various user options for backward
compatibility; leave display-buffer-alist out, and those options will
have no effect on behavior whatsoever, IIUC.

> If so, it might be good to revert everything and postphone these
> changes to 24.2.

Alternatively, we could postpone the pretest and invest the time into
this issue now.  IMO, reverting everything, or even a large portion of
it, would be extremely unkind to Martin's efforts, especially that the
only reason for that is our self-imposed date of pretest start.  That
date is by no means sacred.  We should cherish significant
contributions like this one much more than we cherish the schedule of
Emacs releases.