GNU bug report logs -
#69983
Use category for display-buffer-alist
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Sun, 24 Mar 2024 17:22:01 UTC
Severity: normal
Fixed in version 30.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rudalics <at> gmx.at, 69983 <at> 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.
This bug report was last modified 1 year and 30 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.