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

Karthik Chikmagalur <[email protected]> Wed, 12 Aug 2026 16:13:13 -0700
Newsgroups gmane.emacs.devel
Message-ID <[email protected]>
>  > The display-buffer machinery has a reputation for being arcane and
>  > complicated, and adding more overrides makes this worse.  Most users
>  > find it very hard to internalize the API knowledge required to get
>  > window display to work sanely (for each user's individual definition of
>  > sane).
>
> 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.

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.

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.

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.

Karthik