Re: display-buffer-alist simplifications

[martin rudalics <rudalics@gmx.at>]

 >> (setq
 >>  display-buffer-alist
 >>  '((((regexp . ".*"))
 >>     (reuse-window other same)
 >>     (reuse-window-even-sizes . t)
 >>     (reuse-window other other)
 >>     (reuse-window-even-sizes . nil))))
 >
 > 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.  With Emacs 23 the ordering was implicily specified by the
coding and was explained only in the Elisp manual.  Despite the fact
that Eli spent some time writing the documentation, we had complaints
that it still left out many things.

 > Semantically it is
 > even more complicated than font-lock-keywords---which isn't even
 > user-customizable.

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.

For example, Emacs 23 doesn't allow the user to directly specify that a
buffer should not go to the selected window.  The not-this-window
argument was provided specifically for applications to state that fact.
Users had to write a special-display function to do that.

 > For example, suppose I want Emacs to (i) always avoid displaying in the
 > current window first, even if the display-buffer specifier says so;

Please don't use the formulation "avoid" with `display-buffer-alist'.
Try to formulate in a positive sense: Which window shall be reused
instead when the application's specifer says to use the selected one?

 > (ii)
 > when trying to reuse a window that already has the desired buffer on the
 > current frame, also try looking in other frames at the same time;

This is not very clear (and was even less so in Emacs 23, but that's a
separate story).  Please say which frames it should investigate in which
order - "at the same time" is too vague.  Also say whether in (ii) you
would still insist on using another window but the selected one.

 > and
 > (iii) if all other specifiers fail, fall back on using the current
 > window.  How is that done?

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)

 >> 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 theuser wants it to do
something different.  If everything the user specifies already means to
do something different, we would have to invert the meaning of labels in
the sense of "if the label matches don't do something different but do
what the application wants".

martin