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

>>> 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.
>
> Adding a command like describe-repeat-maps, e.g. describe-display-buffer
> could help to better describe the effect of display-buffer-alist.

I'm not sure about the utility of this -- display-buffer-alist supports
too many behaviors to describe in a friendly way.  And if you're just
printing action arguments as is, it's not much better than looking at
its value in a help buffer.

> Also an option for debugging to display the matched rule in the echo area
> after displaying every buffer.

This sounds very useful.  I've had many head-scratching incidents of
windows popping up in a way that appears to ignore my
display-buffer-alist, only to realize that it matched some other,
earlier rule as a false positive.

Displaying the matched rule via a display-buffer-verbose option would be
great.

>> 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.
>
> Maybe we need more interactive commands that help to build
> display-buffer-alist.  Such as e.g. add-file-local-variable-prop-line
> helps to build the file local variables, and customize-dirlocals
> with add-dir-local-variable helps to build the dir-local file.

I think new users might appreciate a command to assign a rule for
"buffers like this one".  But any list of interactive choices it
presents is going to be very limited.  Also, this command will write
display-buffer-alist to the custom block/file?  On the whole, I'm not
sure that's a good idea.

>> 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.
>
> OTOH, new variables are not intended for user customization,
> so most users don't need to know about them.

This is unfortunately not true.  You can customize display-buffer-alist
to specify exactly what you want, but a package can (and some do) still
override it using the overriding-* let-bindings.  When you investigate
why it doesn't work, you end up having to learn about
display-buffer-overriding-* and the growing precedence list of
display-buffer options.  This is how I first learnt about
display-buffer-overriding-action.

(I've also made display-buffer-overriding-action work _for_ me to
override package behavior, so this is not a blanket complaint
against its existence.)

Karthik