Re: master 8a88f3ed5ae: Add `outline-occur' command and `display-buffer-default-alist' variable

 >> I hardly call 'display-buffer' in my personal files.
 >
 > I mean the display-buffer-alist machinery.  Even if you never call
 > display-buffer, every package (built-in or installed) that needs to show
 > you a buffer does, so display-buffer-alist and its companion variables
 > are constantly in play.
 >
 >> Everything there must be rigid and deterministic in the choice of how
 >> windows display buffers.
 >
 > Yes, but getting your Emacs to this point is not easy.  Emacs'
 > unpredictable buffer display behavior is one of the top complaints of
 > new and intermediate users.  Unpredictable window placement is very
 > annoying and does not let them build a working mental model of Emacs.

It took me more than twenty years to get there.  Nowadays the mechanisms
that get into my way are gdb which I can't avoid to use when debugging
emacs -Q and ediff, something too complex to rewrite from scratch.  The
most annoying fact about these is that they insist on restoring window
configurations.  gdb, in particular, does it all the time and in
addition insists on making windows dedicated.  In most other occasions
my private routines work satisfactorily but I hardly ever use external
packages.  And I certainly don't recommend my approach to other users.

 > When they decide to read the "Displaying Buffers" section of the manual,
 > they are completely overwhelmed by the number of options and precedences
 > between them, and the structure of display-buffer-alist and the action
 > arguments.

IMHO the initial crux was to provide action functions - the Pandora's
box of buffer display.  Over the years they piled up and there's no
foreseeable end to that process.  The command prefix stuff did the rest.

 > It is in this context that I meant that adding a
 > display-buffer-overriding-alist without deprecating
 > display-buffer-overriding-action makes things worse, especially after
 > the recent addition of display-buffer-default-alist.

We can't deprecate 'display-buffer-overriding-action'.  But I think that
'display-buffer-default-alist' has the necessary ingredients to handle
the case where a program has to rely on a generic ‘display-buffer’ call
and at the same time wants to override parts of its default behavior.

Since we have to continue with action functions forever maybe something
like

(defun foo (buffer)
   (let ((display-buffer-overriding-action
	 '(nil (inhibit-same-window . t))))
     (display-buffer buffer)))

(defun foobar (buffer alist)
   (display-buffer-same-window
    buffer (cons '(inhibit-same-window . nil) alist)))

(defun bar (buffer)
   (let ((display-buffer-default-alist
	 `((,(regexp-quote (buffer-name buffer)) (foobar)))))
     (foo buffer)))

(bar (get-buffer-create "*bar*"))

where 'foo' by default uses another window and 'bar' insists on using
the same window would do.

 > The reason for adding both display-buffer-overriding-alist and
 > display-buffer-default-alist make sense to me.  But then I internalized
 > how display-buffer-alist (& co) work a long time ago and I can
 > understand this extra complexity as incremental changes.  I was
 > remarking that the overall level of complexity of display-buffer keeps
 > growing, which is not a good thing.

Agreed.

martin