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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rudalics@gmx.at,  69983@debbugs.gnu.org
> Date: Tue, 09 Apr 2024 19:34:59 +0300
> 
> >> >>> One problem is that I can't find an alist item to limit
> >> >>> the window height, i.e. can't find window-max-height
> >> >>> that would be like window-min-height, but to set a max height.
> >> >>> Could you suggest such an alist item?
> >> >>
> >> >> The intention was to have such behavior:
> >> >> 1. after the first call that adds 1 line to the output buffer,
> >> >>     resize the displayed buffer to 1 line height;
> >> >> 2. after the second call grow the output window height to 2 lines,
> >> >>     it seems fit-window-to-buffer should do this;
> >> >> 3. after 10th call limit the window height to 10 lines only,
> >> >>     so later calls should not increase the output window height
> >> >>     more than 10 lines.
> >> >
> >> > You mean that when a 'window-height' action alist entry is provided that
> >> > specifies 'fit-window-to-buffer' as 'window-height' value, we should
> >> > pass it the value of any 'window-max-height' entry present as MAX-HEIGHT
> >> > argument here
> >> >
> >> >          ((functionp height)
> >> >    (ignore-errors (funcall height window))
> >> >
> >> > and probably do the same for all the other arguments of
> >> > 'fit-window-to-buffer'?
> >>
> >> Probably we can't change the existing arguments to not break
> >> backward-compatibility.  But this is fine since still can use
> >> the explicit function call:
> >>
> >> diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
> >> index 8b43c6a8726..75b519067ac 100644
> >> --- a/lisp/emacs-lisp/warnings.el
> >> +++ b/lisp/emacs-lisp/warnings.el
> >> @@ -362,7 +362,12 @@ display-warning
> >
> > Why does adding a new feature require changes in existing features,
> > let alone such basic features as warnings.el?  Can't we introduce the
> > category and leave warnings.el, flymake.el, and others alone?  I don't
> > want to make unsolicited changes in those other places, because that
> > runs the risk of disturbing people's arrangements of windows and their
> > habits as to where the various windows pop up.
> 
> This is part of continuing development to improve
> window handling for users of horizontally split windows.

I don't think I understand how category is related to horizontally
split windows, please explain.  We are still in the context of
bug#69983 and its Subject, aren't we?

If there are some problems related to horizontally split windows that
interfere with showing warnings, please describe them.