Re: display-buffer-alist simplifications

[martin rudalics <rudalics@gmx.at>]

 >   (defvar display-buffer-alist nil
 >     "Specifications of user preferences for `display-buffer'.
 >   This is a list of elements of the form (CONDITION . ACTION)
 >   where CONDITION is either a regexp matching buffer names, or a function
 >   that takes a buffer and returns a boolean.
 >   ACTION is a list of the form (FUNCTION . ALIST) where FUNCTION can be
 >   either a function or a list of functions.  Those functions will be called
 >   with 2 arguments: the buffer to display and an ALIST built from the various
 >   alists specified in the various ACTIONs.  It should either return the
 >   window used, or nil to fallback to the next function.")

This is what I'd call a `display-buffer-alist' purely built from macro
specifiers.

 >   (defvar display-buffer-default-action (list #'display-buffer-default)
 >     "Default action to perform to display a buffer.
 >   This is an ACTION just like in `display-buffer-alist'.")
 >
 >   (defvar display-buffer-overriding-action '(nil)
 >     "Overriding action to perform to display a buffer.
 >   This is an ACTION just like in `display-buffer-alist'.")
 >
 >   (defun display-buffer (&optional buffer action)
 >     "Display BUFFER in some window."
 >     (let* ((user-action
 >             (assq-regexp (buffer-name buffer) display-buffer-alist))
 >           (functions (append (car display-buffer-overriding-action)
 >                              (car user-action)
 >                              (car action)

Here the user has only two choices: Either accept the (car action) with
its alist or use its own (car user-action) with its own alist.

 >                              (car display-buffer-default-action)))
 >           (alist (append (cdr display-buffer-overriding-action)
 >                          (cdr user-action)
 >                          (cdr action)
 >                          (cdr display-buffer-default-action))))
 >       (run-with-args-until-success functions buffer alist)))
 >
 >   (defalias 'display-buffer-default 'emacs23-display-buffer)
 >
 >   (defun display-buffer-other-window (buffer alist)
 >     (let ((pop-up-windows t)
 >           (special-display-buffer-names nil)
 >           (special-display-regexps nil)
 >           (same-window-buffer-names nil)
 >           (same-window-regexps nil))
 >       (emacs23-display-buffer buffer)))

IIUC this is the Emacs23 compatible version skillful users can override
by supplying their own version.  I'm not quite sure how they would
indicate such a preference via `display-buffer-alist' but apparently the
"function that takes a buffer and returns a boolean" together with some
knowledge about the command that is currently executed should allow them
to do that.


My basic problem with your approach is the following: When we write a
`display-buffer-near-minibuffer' function that reuses the bottom window,
we have two choices wrt evening window heights - do it or don't do it.
As we know, some users are picky about their customizations.  Most of
them, I suppose, got used to the default.  But Eli, for example, doesn't
like `display-buffer' to even window heights.  So we'll soon find
someone who wants the opposite behavior.  And you will propose to
respect the value of the good old `even-window-heights' option in
`display-buffer-near-minibuffer'.  Why would I be not surprised?

As a next step suppose Chong wants to adjust the height of the new
window created by `display-buffer-near-minibuffer' calling, for example,
`fit-window-to-buffer'.  We'll soon find someone who dislikes this
behavior and wants `display-buffer' to leave the new height alone.  So
someone will propose to add a new user option to turn that behavior off.
And people will continue adding new options as they did with
special-display-..., same-window-..., display-buffer-reuse-frames, and
display-buffer-mark-dedicated.

The `display-buffer-alist' idea was to radically put an end to that.
This means that such options can be added _exclusively_ via the alist
and no new variables must be introduced.  And obviously it would have
prompted users to customize it in order to get the behavior they want.
But the interaction between options would have been based on a strict
priority.  Emacs 23 options are not manageable in this regard.

Your approach will divide Emacs users into two groups: A wide majority
that continues to use the old options and a small minority able to write
their own alist based functions.  Since applications cater for the
majority, clones of your `display-buffer-other-window' code above would
abound soon.

Most of what you propose above is easily available in Emacs 23 via
`special-display-regexps'.  An application would just temporarily add
the buffer, the function, and the alist to the head of that and get the
behavior without setting any arguments.  Is it really worth inventing a
new `display-buffer' in order to resolve such cosmetic issues?

martin