Re: display-buffer-alist simplifications

[Chong Yidong]

Juri Linkov <address@hidden> writes:

>>   (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.
>
> In defface specs parameters like `min-width 10' are specified in the
> condition part of `defface' like `min-colors 88' as a list.
> For non-conditional parameters I agree that the plist syntax is better.
> And defface spec merges plist attributes from inherited faces.

I don't know why the condition part of defface specs doesn't use a
plist, and always figured it was a historical accident.  But you raise a
good point---the defface analogy helps clarify how to think about buffer
display specs.  Let's see where this analogy leads.

Currently, `display-buffer-alist' stores lists of specifiers.  Each
specifier can specify either

  (1) A set of conditions, e.g. "display by reusing an existing window"
      and "the window must be already showing the buffer".

or

  (2) "Extra" properties, like (pop-up-frame-function . foo) or
      (reuse-window-even-sizes . t).

If (1) is analogous to the display type in a defface spec and (2) is
analogous to face properties, then instead of lumping (1) and (2) into a
single list, a specifier should have a form like

  (CONDITIONS ATTRIBUTES)

e.g. something like

  (((method reuse-window) (buffer same) (window other))
   (:even-sizes t :reuse-dedicated t))

or maybe

  ((:method reuse-window :buffer same :window other)
   (:even-sizes t :reuse-dedicated t))

Then, "merging" `display-buffer-alist' into the `display-buffer'
specifier arg means combining the attributes for specifiers with the
"same" conditional.  But what does "the same conditional" mean?

In the current design, a (reuse-window-dedicated . t) appearing in
`display-buffer-alist' affects ALL instances of `reuse-window'
specifiers in the specifier list.  (Or something like that---AFAICT it
affects all except those after another `reuse-window-dedicated' cons
cell.  This is one of the things that bugs me about the design.)

So, should "the same conditional" mean `equal'?  Then it will no longer
be possible to use a single display-buffer-alist to affect ALL
`reuse-window' conditional specs passed to `display-buffer'.  I am
personally fine with that.