[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: display-buffer-alist simplifications

From: Eli Zaretskii
Subject: Re: display-buffer-alist simplifications
Date: Wed, 27 Jul 2011 00:59:28 -0400

> From: Chong Yidong <address@hidden>
> Date: Tue, 26 Jul 2011 22:43:20 -0400
> Cc: address@hidden
>   (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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]