Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <address@hidden> writes:

> First of all you would have to give me some idea of what
> `display-buffer-fallback-alist' should look like.  Should it be
> constructed from the same associations as `display-buffer-alist'?

Yes, that is the idea.

> why do you think it's better to pay for removing the (override . t)
> entries (which should be fairly rare BTW) with another variable and a
> doc-string that would either have to refer to that of
> `display-buffer-alist' or replicate most of the latter.

Because that would simplify the meaning of both variables, by making
every specifier be a particular way to finding a window to display
in---with no exceptions.

>> Having gone through these examples, I am convinced that the cost of
>> this design outweighs the benefits.
>
> Can you tell me what you mean by "cost of the design" and how exactly
> you want to avoid that cost.  You cannot avoid merging specifiers
> unless you duplicate each and every component like `even-sizes' in
> each and every specifier.  In the latter case the cost of maintaining
> an option like `display-buffer-alist' would clearly outweigh any
> benefits gained by making the design less expensive.

One cost is that, from your previous message, it conflicts with using a
plist syntax like

  (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.

> Now shouldn't we rather back out all buffer display changes I've
> applied recently and revert to using the old Emacs 23 options?

I like the display specifier argument to `display-buffer' (with the
aboves changes to the syntax to make them easier to understand); it
seems like a real improvement in the way Lisp programs handle window and
buffer switching.

What I find problematic is `display-buffer-alist' and specifier merging.
I don't like the idea that each specifier lacks a self-contained
meaning, because it can be modified by other specifiers.  IIUC, even
with these complications it's still not as flexible as real Lisp code
(e.g. in situations where you want to merge in a specifier if and only
if the original specifier had some specific form).

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).  This way, the display specifier functionality is at
least accessible to Lisp programs for 24.1.  Do you think this is
feasible, or do you think that it's impractical, e.g. because the plist
syntax is fundamentally incompatible with merging?  If so, it might be
good to revert everything and postphone these changes to 24.2.