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