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

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

[Juri Linkov]

'display-comint-buffer-action' and 'display-tex-shell-buffer-action'
are out of place in window.el, and they are redundant per se.

What these variables are trying to achieve is already possible
to do by using a 'category' in 'display-buffer-alist'.
Here is an already supported example:

#+begin_src emacs-lisp
(add-to-list 'display-buffer-alist
             `(,(lambda (_buffer-name action)
                  (eq (alist-get 'category action) 'comint))
               (display-buffer-in-direction)
	       (direction . top)))

(display-buffer (get-buffer-create "blablabla")
		'(nil (category . comint)))
#+end_src

The advantage of this approach is removing a need
of writing a complex regexp to match the buffer name.

Using this approach it's possible just to mark
all related callers with the same category, e.g.:

diff --git a/lisp/cmuscheme.el b/lisp/cmuscheme.el
index c84a1809322..ccd7f2f713f 100644
--- a/lisp/cmuscheme.el
+++ b/lisp/cmuscheme.el
@@ -238,7 +238,7 @@ run-scheme
 	(inferior-scheme-mode)))
   (setq scheme-program-name cmd)
   (setq scheme-buffer "*scheme*")
-  (pop-to-buffer "*scheme*" display-comint-buffer-action))
+  (pop-to-buffer "*scheme*" '(nil (category . comint))))

diff --git a/lisp/progmodes/inf-lisp.el b/lisp/progmodes/inf-lisp.el
index 141bd18cf1e..1aa3bbd4239 100644
--- a/lisp/progmodes/inf-lisp.el
+++ b/lisp/progmodes/inf-lisp.el
@@ -308,7 +308,7 @@ inferior-lisp
 			   "inferior-lisp" (car cmdlist) nil (cdr cmdlist)))
 	(inferior-lisp-mode)))
   (setq inferior-lisp-buffer "*inferior-lisp*")
-  (pop-to-buffer "*inferior-lisp*" display-comint-buffer-action))
+  (pop-to-buffer "*inferior-lisp*" '(nil (category . comint))))

Or we need to keep backward-compatibility?  Then the first step
to deprecate there variables would be something like this:

diff --git a/lisp/window.el b/lisp/window.el
index bea050e181c..fa417817d1d 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -8912,7 +8944,7 @@ pop-to-buffer-same-window
 another window."
   (pop-to-buffer buffer display-buffer--same-window-action norecord))
 
-(defcustom display-comint-buffer-action display-buffer--same-window-action
+(defcustom display-comint-buffer-action (append display-buffer--same-window-action '((category . comint)))
   "`display-buffer' action for displaying comint buffers."
   :type display-buffer--action-custom-type
   :risky t

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

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > 'display-comint-buffer-action' and 'display-tex-shell-buffer-action'
 > are out of place in window.el, and they are redundant per se.
 >
 > What these variables are trying to achieve is already possible
 > to do by using a 'category' in 'display-buffer-alist'.

...

 > Or we need to keep backward-compatibility?  Then the first step
 > to deprecate there variables would be something like this:

Please proceed as carefully as possible, here might be dragons.

martin

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

[Juri Linkov]

>> What these variables are trying to achieve is already possible
>> to do by using a 'category' in 'display-buffer-alist'.
>
> Please proceed as carefully as possible, here might be dragons.

Ok, but before proceeding I propose the following change.
To simplify a complicated lambda condition in

(add-to-list 'display-buffer-alist
             `(,(lambda (_buffer-name action)
                  (eq (alist-get 'category action) 'comint))
               (display-buffer-in-direction)
	       (direction . top)))

let's use a symbol instead of the lambda:

(add-to-list 'display-buffer-alist
             `(comint
               (display-buffer-in-direction)
	       (direction . top)))

Then like strings are used as regexp to match a buffer name
symbols will match a category.

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

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Ok, but before proceeding I propose the following change.

Would this imply a change in 'buffer-match-p'?

martin

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

[Juri Linkov]

>> Ok, but before proceeding I propose the following change.
>
> Would this imply a change in 'buffer-match-p'?

Indeed, here it a simple change in 'buffer-match-p'
that will support this case:

(add-to-list 'display-buffer-alist
             `((category . comint)
               (display-buffer-in-direction)
	       (direction . top)))

(display-buffer (get-buffer-create "blablabla")
		'(nil (category . comint)))

diff --git a/lisp/subr.el b/lisp/subr.el
index b68aa073ba0..2d104c545f0 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -7502,6 +7502,8 @@ buffer-match-p
                               (push condition buffer-match-p--past-warnings))
                             (apply condition buffer-or-name
                                    (if args nil '(nil)))))))
+                      (`(category . ,category)
+                       (eq (alist-get 'category (car args)) category))
                       (`(major-mode . ,mode)
                        (eq
                         (buffer-local-value 'major-mode buffer)

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 188 bytes --]

>> Would this imply a change in 'buffer-match-p'?
>
> Indeed, here it a simple change in 'buffer-match-p'
> that will support this case:

Ok, here is a complete patch with documentation:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: buffer-match-category.patch --]
[-- Type: text/x-diff, Size: 1967 bytes --]

diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi
index eef05d94fdb..54e563eeb58 100644
--- a/doc/lispref/windows.texi
+++ b/doc/lispref/windows.texi
@@ -2638,6 +2638,23 @@ Choosing Window
 @code{buffer-match-p} could fail to report a match if
 @code{display-buffer} is called before the major mode of the buffer is
 set.
+
+When the caller of @code{display-buffer} passes a category as a symbol
+in its @var{action} argument, then @code{display-buffer-alist} can use it
+to match a whole category of buffers with different buffer names,
+for example:
+
+@example
+@group
+(setopt
+ display-buffer-alist
+ (cons '((category . comint) (display-buffer-same-window))
+        display-buffer-alist))
+
+(display-buffer (get-buffer-create "*my-shell*")
+		'(nil (category . comint)))
+@end group
+@end example
 @end defopt
 
 @defopt display-buffer-base-action
diff --git a/lisp/subr.el b/lisp/subr.el
index 90dbfc75d52..9319acefbf1 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -7476,6 +7474,8 @@ buffer-match-p
   * `major-mode': the buffer matches if the buffer's major mode
     is eq to the cons-cell's cdr.  Prefer using `derived-mode'
     instead when both can work.
+  * `category': the buffer matches if the caller of `display-buffer'
+    provided `(category . symbol)' in its ACTION argument.
   * `not': the cadr is interpreted as a negation of a condition.
   * `and': the cdr is a list of recursive conditions, that all have
     to be met.
@@ -7504,6 +7504,8 @@ buffer-match-p
                               (push condition buffer-match-p--past-warnings))
                             (apply condition buffer-or-name
                                    (if args nil '(nil)))))))
+                      (`(category . ,category)
+                       (eq (alist-get 'category (cdar args)) category))
                       (`(major-mode . ,mode)
                        (eq
                         (buffer-local-value 'major-mode buffer)

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

[Eli Zaretskii]

> Cc: 69983@debbugs.gnu.org
> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 28 Mar 2024 09:47:37 +0200
> 
> diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi
> index eef05d94fdb..54e563eeb58 100644
> --- a/doc/lispref/windows.texi
> +++ b/doc/lispref/windows.texi
> @@ -2638,6 +2638,23 @@ Choosing Window
>  @code{buffer-match-p} could fail to report a match if
>  @code{display-buffer} is called before the major mode of the buffer is
>  set.
> +
> +When the caller of @code{display-buffer} passes a category as a symbol

Please use "If", not "When" in such cases.  "When" has a meaning of
time, which is not what you mean here.

> +in its @var{action} argument, then @code{display-buffer-alist} can use it
> +to match a whole category of buffers with different buffer names,
> +for example:
> +
> +@example
> +@group
> +(setopt
> + display-buffer-alist
> + (cons '((category . comint) (display-buffer-same-window))
> +        display-buffer-alist))
> +
> +(display-buffer (get-buffer-create "*my-shell*")
> +		'(nil (category . comint)))
> +@end group

I failed to understand from the description and the example the
meaning of 'category' in this case.  Specifically, I think the
description should tell more about the interpretation of the symbol in
(category . SYMBOL).  The example gives 'comint' as the category
symbol and says this matches "a whole category of buffers", but
doesn't explain enough to understand which buffers will match this
category and which won't.  IOW, the meaning of 'comint' as "category
of buffers" is not sufficiently explained.

> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -7476,6 +7474,8 @@ buffer-match-p
>    * `major-mode': the buffer matches if the buffer's major mode
>      is eq to the cons-cell's cdr.  Prefer using `derived-mode'
>      instead when both can work.
> +  * `category': the buffer matches if the caller of `display-buffer'
> +    provided `(category . symbol)' in its ACTION argument.

Same here.  (And "symbol" should be "SYMBOL", upper-case, I think.

Thanks.

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

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Ok, here is a complete patch with documentation:

+  * `category': the buffer matches if the caller of `display-buffer'
+    provided `(category . symbol)' in its ACTION argument.

IIUC 'buffer-match-p' may be called from anywhere.  Hence,
mentioning 'display-buffer' here seems confusing at least.

martin

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

> Please use "If", not "When" in such cases.  "When" has a meaning of
> time, which is not what you mean here.
>
>> +in its @var{action} argument, then @code{display-buffer-alist} can use it
>> +to match a whole category of buffers with different buffer names,
>> +for example:
>> +
>> +@example
>> +@group
>> +(setopt
>> + display-buffer-alist
>> + (cons '((category . comint) (display-buffer-same-window))
>> +        display-buffer-alist))
>> +
>> +(display-buffer (get-buffer-create "*my-shell*")
>> +		'(nil (category . comint)))
>> +@end group
>
> I failed to understand from the description and the example the
> meaning of 'category' in this case.  Specifically, I think the
> description should tell more about the interpretation of the symbol in
> (category . SYMBOL).  The example gives 'comint' as the category
> symbol and says this matches "a whole category of buffers", but
> doesn't explain enough to understand which buffers will match this
> category and which won't.  IOW, the meaning of 'comint' as "category
> of buffers" is not sufficiently explained.

Now this is improved in the patch below.

>> --- a/lisp/subr.el
>> +++ b/lisp/subr.el
>> @@ -7476,6 +7474,8 @@ buffer-match-p
>>    * `major-mode': the buffer matches if the buffer's major mode
>>      is eq to the cons-cell's cdr.  Prefer using `derived-mode'
>>      instead when both can work.
>> +  * `category': the buffer matches if the caller of `display-buffer'
>> +    provided `(category . symbol)' in its ACTION argument.
>
> Same here.  (And "symbol" should be "SYMBOL", upper-case, I think.

Actually symbol is not a function argument here.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: buffer-match-category.patch --]
[-- Type: text/x-diff, Size: 2291 bytes --]

diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi
index eef05d94fdb..90cd8d2f2da 100644
--- a/doc/lispref/windows.texi
+++ b/doc/lispref/windows.texi
@@ -2638,6 +2638,29 @@ Choosing Window
 @code{buffer-match-p} could fail to report a match if
 @code{display-buffer} is called before the major mode of the buffer is
 set.
+
+If the caller of @code{display-buffer} passes a category as a symbol
+in its @var{action} argument, then you can use the same category in
+@code{display-buffer-alist} to match buffers with different names,
+for example:
+
+@example
+@group
+(setopt
+ display-buffer-alist
+ (cons '((category . comint) (display-buffer-same-window))
+        display-buffer-alist))
+
+(display-buffer (get-buffer-create "*my-shell*")
+		'(nil (category . comint)))
+@end group
+@end example
+
+Regardless of the displayed buffer's name the caller defines a category
+as a symbol @code{comint}.  Then @code{display-buffer-alist} matches
+this category for all buffers displayed with the same category.
+This avoids the need to construct a complex regular expression
+that matches a buffer name.
 @end defopt
 
 @defopt display-buffer-base-action
diff --git a/lisp/subr.el b/lisp/subr.el
index 90dbfc75d52..da57f917da8 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -7476,6 +7474,9 @@ buffer-match-p
   * `major-mode': the buffer matches if the buffer's major mode
     is eq to the cons-cell's cdr.  Prefer using `derived-mode'
     instead when both can work.
+  * `category': the buffer matches a category as a symbol if
+    the caller of `display-buffer' provides `(category . symbol)'
+    in its action argument.
   * `not': the cadr is interpreted as a negation of a condition.
   * `and': the cdr is a list of recursive conditions, that all have
     to be met.
@@ -7504,6 +7505,8 @@ buffer-match-p
                               (push condition buffer-match-p--past-warnings))
                             (apply condition buffer-or-name
                                    (if args nil '(nil)))))))
+                      (`(category . ,category)
+                       (eq (alist-get 'category (cdar args)) category))
                       (`(major-mode . ,mode)
                        (eq
                         (buffer-local-value 'major-mode buffer)

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

[Juri Linkov]

>> Ok, here is a complete patch with documentation:
>
> +  * `category': the buffer matches if the caller of `display-buffer'
> +    provided `(category . symbol)' in its ACTION argument.
>
> IIUC 'buffer-match-p' may be called from anywhere.  Hence,
> mentioning 'display-buffer' here seems confusing at least.

But only 'display-buffer' provides a category.
We can't suggest to use it for other purposes.

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

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > But only 'display-buffer' provides a category.
 > We can't suggest to use it for other purposes.

I don't understand why.  But if so, you should say that this works only
when called from 'display-buffer'.

martin

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

[Juri Linkov]

>> But only 'display-buffer' provides a category.
>> We can't suggest to use it for other purposes.
>
> I don't understand why.

None of other callers supplies its action list to 'buffer-match-p'.

> But if so, you should say that this works only
> when called from 'display-buffer'.

This already says so:

diff --git a/lisp/subr.el b/lisp/subr.el
index b68aa073ba0..da57f917da8 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -7474,6 +7474,9 @@ buffer-match-p
   * `major-mode': the buffer matches if the buffer's major mode
     is eq to the cons-cell's cdr.  Prefer using `derived-mode'
     instead when both can work.
+  * `category': the buffer matches a category as a symbol if
+    the caller of `display-buffer' provides `(category . symbol)'
+    in its action argument.
   * `not': the cadr is interpreted as a negation of a condition.
   * `and': the cdr is a list of recursive conditions, that all have
     to be met.

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

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 >> But if so, you should say that this works only
 >> when called from 'display-buffer'.
 >
 > This already says so:
...
 > +  * `category': the buffer matches a category as a symbol if
 > +    the caller of `display-buffer' provides `(category . symbol)'
 > +    in its action argument.
...

I was never really fond of using 'buffer-match-p' for 'display-buffer'.
This is an example why.  A caller of 'buffer-match-p' who does not know
about 'display-buffer' has to care about whether the CONDITION passed to
it contains a 'category' element.

martin

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

[Juri Linkov]

>>> But if so, you should say that this works only
>>> when called from 'display-buffer'.
>>
>> This already says so:
> ...
>> +  * `category': the buffer matches a category as a symbol if
>> +    the caller of `display-buffer' provides `(category . symbol)'
>> +    in its action argument.
> ...
>
> I was never really fond of using 'buffer-match-p' for 'display-buffer'.
> This is an example why.  A caller of 'buffer-match-p' who does not know
> about 'display-buffer' has to care about whether the CONDITION passed to
> it contains a 'category' element.

A caller of 'buffer-match-p' does not need to care about 'category'.
Only a user who customizes 'display-buffer-alist' needs to care about 'category'.

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

[Juri Linkov]

> A caller of 'buffer-match-p' does not need to care about 'category'.
> Only a user who customizes 'display-buffer-alist' needs to care about 'category'.

So pushed now.

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

[Juri Linkov]

>> 'display-comint-buffer-action' and 'display-tex-shell-buffer-action'
>> are out of place in window.el, and they are redundant per se.
>>
>> What these variables are trying to achieve is already possible
>> to do by using a 'category' in 'display-buffer-alist'.
>>
>> Or we need to keep backward-compatibility?  Then the first step
>> to deprecate there variables would be something like this:
>
> Please proceed as carefully as possible, here might be dragons.

Ok, here is a complete patch:

diff --git a/lisp/window.el b/lisp/window.el
index 3867f6fa6ef..29e7310958b 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -8923,7 +8923,8 @@ pop-to-buffer-same-window
 another window."
   (pop-to-buffer buffer display-buffer--same-window-action norecord))
 
-(defcustom display-comint-buffer-action display-buffer--same-window-action
+(defcustom display-comint-buffer-action
+  (append display-buffer--same-window-action '((category . comint)))
   "`display-buffer' action for displaying comint buffers."
   :type display-buffer--action-custom-type
   :risky t
@@ -8931,8 +8932,14 @@ display-comint-buffer-action
   :group 'windows
   :group 'comint)
 
+(make-obsolete-variable
+ 'display-comint-buffer-action
+ "use a `(category . comint)' condition in `display-buffer-alist'."
+ "30.1")
+
 (defcustom display-tex-shell-buffer-action '(display-buffer-in-previous-window
-                                             (inhibit-same-window . t))
+                                             (inhibit-same-window . t)
+                                             (category . tex-shell))
   "`display-buffer' action for displaying TeX shell buffers."
   :type display-buffer--action-custom-type
   :risky t
@@ -8940,6 +8947,11 @@ display-tex-shell-buffer-action
   :group 'windows
   :group 'tex-run)
 
+(make-obsolete-variable
+ 'display-tex-shell-buffer-action
+ "use a `(category . tex-shell)' condition in `display-buffer-alist'."
+ "30.1")
+
 (defun read-buffer-to-switch (prompt)
   "Read the name of a buffer to switch to, prompting with PROMPT.
 Return the name of the buffer as a string.

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

[Juri Linkov]

>>> 'display-comint-buffer-action' and 'display-tex-shell-buffer-action'
>>> are out of place in window.el, and they are redundant per se.
>>>
>>> What these variables are trying to achieve is already possible
>>> to do by using a 'category' in 'display-buffer-alist'.
>>>
>>> Or we need to keep backward-compatibility?  Then the first step
>>> to deprecate there variables would be something like this:
>>
>> Please proceed as carefully as possible, here might be dragons.
>
> Ok, here is a complete patch:

So now pushed.

Here is a new patch that adds the category 'warning' to 'display-warning',
as well as adds the default display action that is like the action in
'debug' that displays the "*Backtrace*" buffer.

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?

diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
index 6c62a56e99c..2a9f5e5d9f9 100644
--- a/lisp/emacs-lisp/warnings.el
+++ b/lisp/emacs-lisp/warnings.el
@@ -358,7 +358,12 @@ display-warning
 		 (or (< (warning-numeric-level level)
 			(warning-numeric-level warning-minimum-level))
 		     (warning-suppress-p type warning-suppress-types)
-		     (let ((window (display-buffer buffer)))
+		     (let ((window (display-buffer
+                                    buffer
+                                    '(display-buffer--maybe-at-bottom
+                                      (window-min-height . 10)
+                                      (window-height . fit-window-to-buffer)
+                                      (category . warning)))))
 		       (when (and (markerp warning-series)
 				  (eq (marker-buffer warning-series) buffer))
 			 (set-window-start window warning-series))

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

[Juri Linkov]

> 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.

But I can't find a setting for this.

> +		     (let ((window (display-buffer
> +                                    buffer
> +                                    '(display-buffer--maybe-at-bottom
> +                                      (window-min-height . 10)
> +                                      (window-height . fit-window-to-buffer)

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

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 >> 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'?

martin

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

[Juri Linkov]

>>> 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
 		 (or (< (warning-numeric-level level)
 			(warning-numeric-level warning-minimum-level))
 		     (warning-suppress-p type warning-suppress-types)
-		     (let ((window (display-buffer buffer)))
+		     (let ((window (display-buffer
+				    buffer
+				    '(display-buffer--maybe-at-bottom
+				      (window-height . (lambda (window)
+					(fit-window-to-buffer window 10)))
+				      (category . warning)))))
 		       (when (and (markerp warning-series)
 				  (eq (marker-buffer warning-series) buffer))
 			 (set-window-start window warning-series))
diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
index 779c612f479..3344402c893 100644
--- a/lisp/progmodes/flymake.el
+++ b/lisp/progmodes/flymake.el
@@ -1866,7 +1866,11 @@ flymake-show-buffer-diagnostics
                        (current-buffer)))))
     (with-current-buffer target
       (setq flymake--diagnostics-buffer-source source)
-      (display-buffer (current-buffer))
+      (display-buffer (current-buffer)
+                      `((display-buffer-reuse-window
+                         display-buffer-below-selected)
+                        (window-height . (lambda (window)
+                          (fit-window-to-buffer window 10)))))
       (revert-buffer))))
 
 \f

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

[Eli Zaretskii]

> Cc: 69983@debbugs.gnu.org
> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 09 Apr 2024 09:30:31 +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.

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

[Juri Linkov]

>> >>> 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.

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.

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

[Juri Linkov]

>> >> >>> 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.

The function 'display-warning' has the argument 'buffer-name'.
This means it's impossible to match the buffer name in
'display-buffer-alist', because the buffer name can be anything.
Therefore the 'category' should be added to the 'display-buffer'
call in 'display-warning'.

Currently the warning buffer is displayed in a random place
in horizontally split windows.  The change is needed to display it
in the consistent place.  This change is accompanied with adding
the category for the case if someone don't like this change
(very unlikely) and wants to revert it to display the buffer
in a random place.  It will be possible to customize this
by using the category in 'display-buffer-alist'.

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

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > The function 'display-warning' has the argument 'buffer-name'.
 > This means it's impossible to match the buffer name in
 > 'display-buffer-alist', because the buffer name can be anything.
 > Therefore the 'category' should be added to the 'display-buffer'
 > call in 'display-warning'.
 >
 > Currently the warning buffer is displayed in a random place
 > in horizontally split windows.

'display-buffer' never chooses a random place.

 > The change is needed to display it
 > in the consistent place.  This change is accompanied with adding
 > the category for the case if someone don't like this change
 > (very unlikely) and wants to revert it to display the buffer
 > in a random place.  It will be possible to customize this
 > by using the category in 'display-buffer-alist'.

I agree with everything else Juri says here.

martin

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: Wed, 10 Apr 2024 09:45:49 +0300
> 
> >> > 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.
> 
> The function 'display-warning' has the argument 'buffer-name'.
> This means it's impossible to match the buffer name in
> 'display-buffer-alist', because the buffer name can be anything.
> Therefore the 'category' should be added to the 'display-buffer'
> call in 'display-warning'.
> 
> Currently the warning buffer is displayed in a random place
> in horizontally split windows.  The change is needed to display it
> in the consistent place.  This change is accompanied with adding
> the category for the case if someone don't like this change
> (very unlikely) and wants to revert it to display the buffer
> in a random place.  It will be possible to customize this
> by using the category in 'display-buffer-alist'.

First, as Martin says, the place is never "random".

More importantly, if we want to let programs and users control where
the warnings are displayed, I'd rather we introduced a new,
warning.el-specific option.  Up front, there's no reason for anyone to
assume that display-buffer-alist will have _any_ effect on
display-warning, because we don't document that display-warning uses
display-buffer.  So we could one day decide to implement the display
of the warnings in an entirely different fashion, and then no
customizations of display-buffer-alist will be able to affect the
display.  In fact, in some situations we already display the warning
other than via display-buffer.

In any case, if you are suggesting to change the "random" place where
warnings are displayed, we should first discuss that, because your
assertion that no one will dislike the change sounds very much like
famous last words to me, so to speak ;-)

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

[Juri Linkov]

>> >> > 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.
>>
>> The function 'display-warning' has the argument 'buffer-name'.
>> This means it's impossible to match the buffer name in
>> 'display-buffer-alist', because the buffer name can be anything.
>> Therefore the 'category' should be added to the 'display-buffer'
>> call in 'display-warning'.
>>
>> Currently the warning buffer is displayed in a random place
>> in horizontally split windows.  The change is needed to display it
>> in the consistent place.  This change is accompanied with adding
>> the category for the case if someone don't like this change
>> (very unlikely) and wants to revert it to display the buffer
>> in a random place.  It will be possible to customize this
>> by using the category in 'display-buffer-alist'.
>
> First, as Martin says, the place is never "random".

The "random" place was meant in the sense "unpredictable".
It uses some least recently used window, but with many windows
it's hard to remember what window was least recently used.

> More importantly, if we want to let programs and users control where
> the warnings are displayed, I'd rather we introduced a new,
> warning.el-specific option.  Up front, there's no reason for anyone to
> assume that display-buffer-alist will have _any_ effect on
> display-warning, because we don't document that display-warning uses
> display-buffer.  So we could one day decide to implement the display
> of the warnings in an entirely different fashion, and then no
> customizations of display-buffer-alist will be able to affect the
> display.  In fact, in some situations we already display the warning
> other than via display-buffer.

These are just excuses to not make life easier for users of
horizontally split windows.

> In any case, if you are suggesting to change the "random" place where
> warnings are displayed, we should first discuss that, because your
> assertion that no one will dislike the change sounds very much like
> famous last words to me, so to speak ;-)

Why discriminate users by their orientation?  If users prefer
nontraditional horizontal orientation why not help them
in situations of horizontally split windows?

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: Wed, 10 Apr 2024 20:49:50 +0300
> 
> > More importantly, if we want to let programs and users control where
> > the warnings are displayed, I'd rather we introduced a new,
> > warning.el-specific option.  Up front, there's no reason for anyone to
> > assume that display-buffer-alist will have _any_ effect on
> > display-warning, because we don't document that display-warning uses
> > display-buffer.  So we could one day decide to implement the display
> > of the warnings in an entirely different fashion, and then no
> > customizations of display-buffer-alist will be able to affect the
> > display.  In fact, in some situations we already display the warning
> > other than via display-buffer.
> 
> These are just excuses to not make life easier for users of
> horizontally split windows.

I don't see how a warning-specific option could be an "excuse".  It
can solve the problem you attempt to solve as well as what you
propose.

And if you think that referring to my views as "excuses" somehow makes
your opinions more convincing, you are wrong.

> > In any case, if you are suggesting to change the "random" place where
> > warnings are displayed, we should first discuss that, because your
> > assertion that no one will dislike the change sounds very much like
> > famous last words to me, so to speak ;-)
> 
> Why discriminate users by their orientation?  If users prefer
> nontraditional horizontal orientation why not help them
> in situations of horizontally split windows?

I don't see how the discussion I suggested could be viewed as
"discrimination".  I feel that there's some fundamental
misunderstanding here.

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

[Juri Linkov]

>> > More importantly, if we want to let programs and users control where
>> > the warnings are displayed, I'd rather we introduced a new,
>> > warning.el-specific option.  Up front, there's no reason for anyone to
>> > assume that display-buffer-alist will have _any_ effect on
>> > display-warning, because we don't document that display-warning uses
>> > display-buffer.  So we could one day decide to implement the display
>> > of the warnings in an entirely different fashion, and then no
>> > customizations of display-buffer-alist will be able to affect the
>> > display.  In fact, in some situations we already display the warning
>> > other than via display-buffer.
>>
>> These are just excuses to not make life easier for users of
>> horizontally split windows.
>
> I don't see how a warning-specific option could be an "excuse".  It
> can solve the problem you attempt to solve as well as what you
> propose.

There is already the option display-buffer-alist.

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: Thu, 11 Apr 2024 09:31:45 +0300
> 
> >> > More importantly, if we want to let programs and users control where
> >> > the warnings are displayed, I'd rather we introduced a new,
> >> > warning.el-specific option.  Up front, there's no reason for anyone to
> >> > assume that display-buffer-alist will have _any_ effect on
> >> > display-warning, because we don't document that display-warning uses
> >> > display-buffer.  So we could one day decide to implement the display
> >> > of the warnings in an entirely different fashion, and then no
> >> > customizations of display-buffer-alist will be able to affect the
> >> > display.  In fact, in some situations we already display the warning
> >> > other than via display-buffer.
> >>
> >> These are just excuses to not make life easier for users of
> >> horizontally split windows.
> >
> > I don't see how a warning-specific option could be an "excuse".  It
> > can solve the problem you attempt to solve as well as what you
> > propose.
> 
> There is already the option display-buffer-alist.

Which I think is not appropriate for customizing what warnings.el
does, for the reasons I explained above.

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

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > In any case, if you are suggesting to change the "random" place where
 > warnings are displayed, we should first discuss that, because your
 > assertion that no one will dislike the change sounds very much like
 > famous last words to me, so to speak ;-)

This part

+				    '(display-buffer--maybe-at-bottom
+				      (window-height . (lambda (window)
+					(fit-window-to-buffer window 10)))

would hard-code a new preference which might cause problems indeed.  But
the subsequent

+				      (category . warning)))))

would allow users to customize the display of warnings via
'display-buffer-alist' and cannot harm otherwise.

martin

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

[Eli Zaretskii]

> Date: Thu, 11 Apr 2024 11:16:25 +0200
> Cc: 69983@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > In any case, if you are suggesting to change the "random" place where
>  > warnings are displayed, we should first discuss that, because your
>  > assertion that no one will dislike the change sounds very much like
>  > famous last words to me, so to speak ;-)
> 
> This part
> 
> +				    '(display-buffer--maybe-at-bottom
> +				      (window-height . (lambda (window)
> +					(fit-window-to-buffer window 10)))
> 
> would hard-code a new preference which might cause problems indeed.  But
> the subsequent
> 
> +				      (category . warning)))))
> 
> would allow users to customize the display of warnings via
> 'display-buffer-alist' and cannot harm otherwise.

I understand, and might even agree.  But (a) as I wrote elsewhere in
this thread, I don't think display-buffer-alist should be the
advertised means of controlling display of warnings, and (b) I happen
to think that display-buffer-alist is so complex and arcane that
asking users to use it as the means of customizing such simple
settings is not very user-friendly, to say the least, especially when
we change existing behavior (which is likely to cause users to want to
get the previous behavior back).

This is why I suggested to discuss the proposed new behavior.  It is
possible that we will all agree that it is superior to the old one, in
which case the above-mentioned considerations will not apply.  But if
not, then the default should reflect what we think most users will
want, and how to implement that takes a back seat.

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

[Juri Linkov]

>> There is already the option display-buffer-alist.
>
> Which I think is not appropriate for customizing what warnings.el
> does, for the reasons I explained above.

As you can see in the Subject, the whole point of this bug report is to
add a category to display-buffer calls, so displaying the warning buffer
can be customized by the existing option 'display-buffer-alist'.

Adding hundreds of separate options for every display-buffer call
makes no sense.

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: Fri, 12 Apr 2024 09:37:10 +0300
> 
> >> There is already the option display-buffer-alist.
> >
> > Which I think is not appropriate for customizing what warnings.el
> > does, for the reasons I explained above.
> 
> As you can see in the Subject, the whole point of this bug report is to
> add a category to display-buffer calls, so displaying the warning buffer
> can be customized by the existing option 'display-buffer-alist'.

I don't object to adding the category to display-buffer-alist.  I
object to using that as a means to control what warnings.el does.  In
particular, as I already pointed out, some warnings don't pop up a
window with a special buffer, so if the users use display-buffer-alist
for controlling warnings.el, they will be disappointed in some cases.

> 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.  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);
  . 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

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

[Juri Linkov]

>> 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.

> 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.

>   . 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.

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: Fri, 12 Apr 2024 19:50:55 +0300
> 
> >> 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.

> > 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.

> >   . 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?

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

>> >> 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:


[-- Attachment #2: warning.png --]
[-- Type: image/png, Size: 31025 bytes --]

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: Sat, 13 Apr 2024 21:49:13 +0300
> 
> > 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.

> > 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 is why I asked for a
detailed definition of "at bottom".

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

[Juri Linkov]

>> > 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'".

>> > 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'.

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: Sun, 14 Apr 2024 19:04:13 +0300
> 
> >> > 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.

> >> > 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.

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.

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

[Juri Linkov]

>> >> > 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.

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: Thu, 18 Apr 2024 20:16:30 +0300
> 
> >> >> > 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.

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

[Juri Linkov]

>> >> >> > 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.

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

[Juri Linkov]

>>> >> >> > 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.

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: Fri, 19 Apr 2024 09:24:10 +0300
> 
> >> 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.

I think the proper solution for that is to introduce a new variable
that would customize what display-warning does.  Doing it with
display-buffer-alist is IMO wrong, for the reasons I explained
up-thread.  I realize that you disagree, but I stand by my opinion.

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: Fri, 19 Apr 2024 09:28:41 +0300
> 
> > 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.

Thank you!

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

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

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

The reason why a new option is needed is because display-warning
doesn't move point to the bottom line with the last message.

So when the warning buffer will be displayed at the bottom of
the screen in a narrow window, but the window always stays
displaying the top of the warning buffer, the users will miss
the last unseen message.

To solve this problem, a new option 'warning-display-at-bottom'
(whose name has the same prefix as all other options in the same file)
will scroll the bottom window, so the last message will always
be visible to the user.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: warning-display-at-bottom.patch --]
[-- Type: text/x-diff, Size: 1724 bytes --]

diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
index 8b43c6a8726..672c9ed4618 100644
--- a/lisp/emacs-lisp/warnings.el
+++ b/lisp/emacs-lisp/warnings.el
@@ -120,6 +120,14 @@ warning-suppress-types
 See also `warning-suppress-log-types'."
   :type '(repeat (repeat symbol))
   :version "22.1")
+
+(defcustom warning-display-at-bottom t
+  "Display the warning buffer at the bottom of the screen.
+The output window will be scrolled to the bottom of the buffer
+to show the last warning message."
+  :type 'boolean
+  :version "30.1")
+
 \f
 ;; The autoload cookie is so that programs can bind this variable
 ;; safely, testing the existing value, before they call one of the
@@ -362,10 +370,20 @@ display-warning
 		 (or (< (warning-numeric-level level)
 			(warning-numeric-level warning-minimum-level))
 		     (warning-suppress-p type warning-suppress-types)
-		     (let ((window (display-buffer buffer)))
+		     (let ((window (display-buffer
+				    buffer
+				    (when warning-display-at-bottom
+                                      '(display-buffer--maybe-at-bottom
+				        (window-height . (lambda (window)
+                                          (fit-window-to-buffer window 10)))
+				        (category . warning))))))
 		       (when (and (markerp warning-series)
 				  (eq (marker-buffer warning-series) buffer))
 			 (set-window-start window warning-series))
+		       (when warning-display-at-bottom
+                         (with-selected-window window
+                           (set-window-point window (point-max))
+                           (recenter -1)))
 		       (sit-for 0)))))))))
 \f
 ;; Use \\<special-mode-map> so that help-enable-autoload can do its thing.

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: Fri, 19 Apr 2024 19:17:14 +0300
> 
> The reason why a new option is needed is because display-warning
> doesn't move point to the bottom line with the last message.
> 
> So when the warning buffer will be displayed at the bottom of
> the screen in a narrow window, but the window always stays
> displaying the top of the warning buffer, the users will miss
> the last unseen message.
> 
> To solve this problem, a new option 'warning-display-at-bottom'
> (whose name has the same prefix as all other options in the same file)
> will scroll the bottom window, so the last message will always
> be visible to the user.

Thanks.

> +		       (when warning-display-at-bottom
> +                         (with-selected-window window
> +                           (set-window-point window (point-max))
> +                           (recenter -1)))

Should we perhaps do the same as end-of-buffer does, i.e.

	 (recenter (if (and scroll-minibuffer-conservatively
	                    (window-minibuffer-p))
	               -1 -3)))))

(or, if the window here can never be a mini-window, just use -3
instead of -1 in the call to recenter)?

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

[Juri Linkov]

>> +		       (when warning-display-at-bottom
>> +                         (with-selected-window window
>> +                           (set-window-point window (point-max))
>> +                           (recenter -1)))
>
> Should we perhaps do the same as end-of-buffer does, i.e.
>
> 	 (recenter (if (and scroll-minibuffer-conservatively
> 	                    (window-minibuffer-p))
> 	               -1 -3)))))

I tried many different things before reaching the 'recenter' solution.
For example, tried everything from the Info node
(info "(emacs) Auto Scrolling") such as scroll-conservatively,
scroll-step, scroll-up-aggressively/scroll-down-aggressively
to avoid recentering after scrolling.  But none of them work,
so an extra step is required to use 'recenter' after moving point.

Also too bad that need to use 'with-selected-window' instead of
'with-current-buffer', since 'recenter' has no 'window' argument.

> (or, if the window here can never be a mini-window, just use -3
> instead of -1 in the call to recenter)?

I don't understand why 'end-of-buffer' leaves 2 additional empty lines
at bottom.  Every time when I use 'M->' (end-of-buffer), I need
to type additional keys to manually scroll more 2 lines down
to remove these 2 empty lines from the screen.

Maybe 'end-of-buffer' should use -1 when 'scroll-conservatively' is set
as this FIXME comment in 'end-of-buffer' suggests:

	 ;; FIXME: Arguably if `scroll-conservatively' is set, then
         ;; we should pass -1 to `recenter'.
	 (recenter (if (and scroll-minibuffer-conservatively
	                    (window-minibuffer-p))
	               -1 -3))

Anyway, the warning buffer is as narrow as the minibuffer,
so -1 is the right value for 'display-warning'.

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: Sun, 21 Apr 2024 09:52:50 +0300
> 
> I don't understand why 'end-of-buffer' leaves 2 additional empty lines
> at bottom.

I think it's so you could type there without causing an immediate
scroll of the window.

> Maybe 'end-of-buffer' should use -1 when 'scroll-conservatively' is set
> as this FIXME comment in 'end-of-buffer' suggests:
> 
> 	 ;; FIXME: Arguably if `scroll-conservatively' is set, then
>          ;; we should pass -1 to `recenter'.
> 	 (recenter (if (and scroll-minibuffer-conservatively
> 	                    (window-minibuffer-p))
> 	               -1 -3))

Maybe.  I believe we added the scroll-minibuffer-conservatively
variable because some people may wish setting it to a value different
from scroll-conservatively.  But we could try your suggestion and see
if people complain.

> Anyway, the warning buffer is as narrow as the minibuffer,
> so -1 is the right value for 'display-warning'.

OK, thanks.

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

[Juri Linkov]

close 69983 30.0.50
thanks

>> Maybe 'end-of-buffer' should use -1 when 'scroll-conservatively' is set
>> as this FIXME comment in 'end-of-buffer' suggests:
>>
>> 	 ;; FIXME: Arguably if `scroll-conservatively' is set, then
>>          ;; we should pass -1 to `recenter'.
>> 	 (recenter (if (and scroll-minibuffer-conservatively
>> 	                    (window-minibuffer-p))
>> 	               -1 -3))
>
> Maybe.  I believe we added the scroll-minibuffer-conservatively
> variable because some people may wish setting it to a value different
> from scroll-conservatively.  But we could try your suggestion and see
> if people complain.
>
>> Anyway, the warning buffer is as narrow as the minibuffer,
>> so -1 is the right value for 'display-warning'.
>
> OK, thanks.

So now pushed to master and closed.

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

[Juri Linkov]

> +(make-obsolete-variable
> + 'display-comint-buffer-action
> + "use a `(category . comint)' condition in `display-buffer-alist'."
> + "30.1")

I noticed this now gives during byte-compilation:

 Warning: `display-comint-buffer-action' is an obsolete variable (as of 30.1)

So probably the best thing to do would be to suppress warnings such as:

diff --git a/lisp/cmuscheme.el b/lisp/cmuscheme.el
index c84a1809322..d4316fb1175 100644
--- a/lisp/cmuscheme.el
+++ b/lisp/cmuscheme.el
@@ -238,7 +238,8 @@ run-scheme
 	(inferior-scheme-mode)))
   (setq scheme-program-name cmd)
   (setq scheme-buffer "*scheme*")
-  (pop-to-buffer "*scheme*" display-comint-buffer-action))
+  (with-suppressed-warnings ((obsolete display-comint-buffer-action))
+    (pop-to-buffer "*scheme*" display-comint-buffer-action)))