emacs-devel
[Top][All Lists]
Advanced

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

Re: display-buffer-alist simplifications


From: Tim Cross
Subject: Re: display-buffer-alist simplifications
Date: Wed, 27 Jul 2011 18:08:26 +1000

On Wed, Jul 27, 2011 at 2:59 PM, Eli Zaretskii <address@hidden> wrote:
>> 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.
>
>

+1

Tim



reply via email to

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