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.