Re: display-buffer-alist simplifications

[Chong Yidong]

martin rudalics <address@hidden> writes:

>> This is not clean.  The specifiers interact with one another, and
>> their ordering affects the behavior of other specifiers.
>
> The ordering is important, yes.  But the ordering is fully controlled
> by the user.
>
> The semantics of `display-buffer-alist' are certainly cleaner than the
> semantics of Emacs 23 options.  With `display-buffer-alist' you only
> specify what _shall_ be done.  You don't care about what shall be
> avoided.  OTOH Emacs 23 options provide a mixture of what should be
> done and what should be avoided.

The topic at hand is whether `display-buffer-alist' should "merge" into
the display specifier supplied to `display-buffer'.  Let's put aside the
question of whether the Emacs 23 system is or is not complicated.

> Tell me what's missing in the form
>
> (setq
>  display-buffer-alist
>  '((((regexp . ".*"))
>     (reuse-window other nil 0)
>     (override . t)
>     (reuse-window same))))
>
> for a call like
>
> (display-buffer "*scratch*" 'same-window)

So, IIUC, this converts the same-window specifier

  ((reuse-window same nil nil))

to

  ((reuse-window other nil 0)
   (reuse-window same nil nil)
   (reuse-window same))

Right?  This form of "merging" can be eliminated by providing a
`display-buffer-fallback-alist', removing the need for (override . t)
and one source of unwanted interaction between specifiers.


Here is the basic point.  You're arguing for a buffer display specifier
syntax that consists of interacting elements, because this syntax allows
`display-buffer-alist' to "merge with" or "influence" the specifiers
supplied to `display-buffer'.  Having gone through these examples, I am
convinced that the cost of this design outweighs the benefits.

It is far more important to use a syntax that is easy to understand.
If I have a list of specifiers

  (A B C ...)

that should mean "try A; if that fails, try B; if that fails, try C".

And not a situation where certain B's are not things to try, but instead
are tags that modify how A behaves, or tags that say how to merge this
list with the argument to `display-buffer', etc.  This kind of
pseudo-programming language is not a good fit to the Emacs concept of
customizable options; the traditional way of providing customizable
programming logic is with hooks and abnormal hooks.


>>> Impossible.  The first consequence of this would be applications
>>> rebinding `display-buffer-alist' to nil around `display-buffer' calls.
>>> How would you implement `info-other-window' or `find-file-other-frame'
>>> when the user has a `display-buffer-alist' entry for *Info* or the file
>>> in question?
>>
>> Isn't that what you introduced labels for?
>
> Labels should be used when the application proposes to do something
> special for a specific command or function but the user wants it to do
> something different.

The point is that `info-other-window' can call display-buffer as

  (display-buffer buf specifiers 'info-other-window)

so the user could override this with

  (setq display-buffer-alist
        '((info-other-window replacement-spec)))

This obviates the need to provide the specifier merging functionality,
without forcing Lisp code like `info-other-window' to bind
display-buffer-alist to nil.