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

[Juri Linkov <juri@linkov.net>]

>>> >> >> > 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.
>
> This is not about customizing display-warning.  This is about
> customizing the display of the warning buffer.  When other
> functions such as 'lwarn' and 'warn' display the warning buffer
> the only way to customize the display of the warning buffer
> is display-buffer-alist.

Sorry, actually you are right, let's add a new option.
Will do this soon.