>> >> Adding hundreds of separate options for every display-buffer call
>> >> makes no sense.
>> >
>> > Adding hundreds of separate options indeed doesn't make sense, but I
>> > suggested to add just one.
>> 
>> The point of this bug report is to remove options, not to add a new ones.
>
> 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.

>> > In addition:
>> >
>> >   . you haven't addressed my comments that currently we don't even
>> >     document that warnings.el uses display-buffer (and neither do I
>> >     think we _should_ document that);
>> 
>> I agree, this should be documented.  Then problem solved.
>
> That's not TRT, because in some cases warnings are not displayed via
> display-buffer.  So documenting this would produce inaccurate
> documentation.

I can't find cases when warnings are not displayed via display-buffer.

>> >   . you haven't explained what kind of behavior change would you like
>> >     to make in how warnings.el displays the warnings, without which
>> >     I'm not even sure I understand the intended change of behavior
>> 
>> The problem of the users of horizontally split windows
>> is that the warning buffer pops up in unpredictable places,
>> thus disrupting the user's window layout.
>> 
>> The proposed change is to always display the warning buffer at the bottom
>> where most contemporary IDEs are displaying such information.
>
> Thanks, but what do you mean by "at the bottom"?  Can you describe
> that place more precisely?

Here is an example: