[Top][All Lists]
[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
- Re: display-buffer-alist simplifications, (continued)
- Re: display-buffer-alist simplifications, Juri Linkov, 2011/07/25
- Re: display-buffer-alist simplifications, Stephen J. Turnbull, 2011/07/25
- Re: display-buffer-alist simplifications, David Kastrup, 2011/07/26
- Re: display-buffer-alist simplifications, Stephen J. Turnbull, 2011/07/26
- Re: display-buffer-alist simplifications, David Kastrup, 2011/07/26
- Re: display-buffer-alist simplifications, Juri Linkov, 2011/07/26
- Re: display-buffer-alist simplifications, martin rudalics, 2011/07/31
- Re: display-buffer-alist simplifications, martin rudalics, 2011/07/31
- Re: display-buffer-alist simplifications, Chong Yidong, 2011/07/26
- Re: display-buffer-alist simplifications, Eli Zaretskii, 2011/07/27
- Re: display-buffer-alist simplifications,
Tim Cross <=
- Re: display-buffer-alist simplifications, Juanma Barranquero, 2011/07/27
- Re: display-buffer-alist simplifications, Juanma Barranquero, 2011/07/27
- Re: display-buffer-alist simplifications, Lars Magne Ingebrigtsen, 2011/07/27
- Re: display-buffer-alist simplifications, David Kastrup, 2011/07/27
- Re: display-buffer-alist simplifications, Juanma Barranquero, 2011/07/27
- Re: display-buffer-alist simplifications, Juanma Barranquero, 2011/07/27
- Re: display-buffer-alist simplifications, Eli Zaretskii, 2011/07/27
- RE: display-buffer-alist simplifications, Drew Adams, 2011/07/27
- Re: display-buffer-alist simplifications, Chong Yidong, 2011/07/28
- Re: display-buffer-alist simplifications, martin rudalics, 2011/07/31