bug#69983: Use category for display-buffer-alist

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: rudalics@gmx.at,  69983@debbugs.gnu.org
> Date: Thu, 18 Apr 2024 20:16:30 +0300
> 
> >> >> > If we want to enable user control of displaying warnings, we will have
> >> >> > to add an option for that, because currently that cannot be
> >> >> > controlled.  display-buffer-alist is inappropriate for such control,
> >> >> > since in some cases warnings are not displayed in pop-up windows.
> >> >>
> >> >> Could you show an example when warnings are not displayed in pop-up windows.
> >> >
> >> > The two calls to 'message' there.
> >>
> >> These calls are irrelevant.  It makes no sense to add an option
> >> to display text "at the bottom of 'message'".
> >
> > Of course.  But what if some user would like to display the warnings
> > in the echo-area?  Don't we want to allow such customization?  If we
> > do, then display-buffer machinery is not relevant, exactly as it is
> > not relevant for those two calls.
> 
> This proves that a new option is not needed.  QED.
> 
> >> >> > Thanks, but what do you mean by "at the bottom"?  Can you describe
> >> >> > that place more precisely?
> >> >>
> >> >> Here is an example:
> >> >
> >> > I understand what this means in the simple cases, but not necessarily
> >> > what happens in more complex cases.
> >>
> >> This case is not simple.  It demonstrates the problem
> >> in horizontally split windows.
> >>
> >> > This is why I asked for a detailed definition of "at bottom".
> >>
> >> The detailed definition is in the documentation of
> >> 'display-buffer-at-bottom'.
> >
> > I agree that "display at bottom" is a useful feature, but why should
> > we decide that users could have no control of that, either?  E.g.,
> > another reasonable MO is to split the selected window vertically and
> > show the warning in the lower window.
> 
> This is easy to customize with a category in display-buffer-alist.
> 
> > So I think display-warning should have a variable to customize its
> > display, and limiting that only to what display-buffer can produce
> > doesn't support all the optional behaviors people could reasonably
> > want.  Moreover, display-buffer is IMO overly-complex for this simple
> > job; a simple variable with several distinct values would do.
> 
> Adding dozens of new variables that replace display-buffer-alist
> makes no sense.

So we disagree.  I stand by my opinion, and will object to making
display-buffer-alist the way of customizing display-warning.