unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#69983: Use category for display-buffer-alist
@ 2024-03-24 17:19 Juri Linkov
  2024-03-25  9:41 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-03-24 17:19 UTC (permalink / raw)
  To: 69983; +Cc: martin rudalics

'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





^ permalink raw reply related	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-24 17:19 bug#69983: Use category for display-buffer-alist Juri Linkov
@ 2024-03-25  9:41 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-25 17:12   ` Juri Linkov
  2024-04-04  6:16   ` Juri Linkov
  0 siblings, 2 replies; 36+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-25  9:41 UTC (permalink / raw)
  To: Juri Linkov, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-25  9:41 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-25 17:12   ` Juri Linkov
  2024-03-26  9:55     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-04  6:16   ` Juri Linkov
  1 sibling, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-03-25 17:12 UTC (permalink / raw)
  To: martin rudalics; +Cc: 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-25 17:12   ` Juri Linkov
@ 2024-03-26  9:55     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-27  7:15       ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-26  9:55 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 69983

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

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

martin






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-26  9:55     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-27  7:15       ` Juri Linkov
  2024-03-28  7:47         ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-03-27  7:15 UTC (permalink / raw)
  To: martin rudalics; +Cc: 69983

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





^ permalink raw reply related	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-27  7:15       ` Juri Linkov
@ 2024-03-28  7:47         ` Juri Linkov
  2024-03-28  8:23           ` Eli Zaretskii
  2024-03-28  9:18           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 36+ messages in thread
From: Juri Linkov @ 2024-03-28  7:47 UTC (permalink / raw)
  To: martin rudalics; +Cc: 69983

[-- 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)

^ permalink raw reply related	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-28  7:47         ` Juri Linkov
@ 2024-03-28  8:23           ` Eli Zaretskii
  2024-03-28 17:46             ` Juri Linkov
  2024-03-28  9:18           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2024-03-28  8:23 UTC (permalink / raw)
  To: Juri Linkov; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-28  7:47         ` Juri Linkov
  2024-03-28  8:23           ` Eli Zaretskii
@ 2024-03-28  9:18           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-28 17:50             ` Juri Linkov
  1 sibling, 1 reply; 36+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-28  9:18 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 69983

 > 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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-28  8:23           ` Eli Zaretskii
@ 2024-03-28 17:46             ` Juri Linkov
  0 siblings, 0 replies; 36+ messages in thread
From: Juri Linkov @ 2024-03-28 17:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rudalics, 69983

[-- 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)

^ permalink raw reply related	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-28  9:18           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-28 17:50             ` Juri Linkov
  2024-03-29  8:43               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-03-28 17:50 UTC (permalink / raw)
  To: martin rudalics; +Cc: 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-28 17:50             ` Juri Linkov
@ 2024-03-29  8:43               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-29 16:30                 ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-29  8:43 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 69983

 > 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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-29  8:43               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-29 16:30                 ` Juri Linkov
  2024-03-30  9:36                   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-03-29 16:30 UTC (permalink / raw)
  To: martin rudalics; +Cc: 69983

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





^ permalink raw reply related	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-29 16:30                 ` Juri Linkov
@ 2024-03-30  9:36                   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-30 18:22                     ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-30  9:36 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-30  9:36                   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-30 18:22                     ` Juri Linkov
  2024-04-02 16:52                       ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-03-30 18:22 UTC (permalink / raw)
  To: martin rudalics; +Cc: 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-30 18:22                     ` Juri Linkov
@ 2024-04-02 16:52                       ` Juri Linkov
  0 siblings, 0 replies; 36+ messages in thread
From: Juri Linkov @ 2024-04-02 16:52 UTC (permalink / raw)
  To: martin rudalics; +Cc: 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-03-25  9:41 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-03-25 17:12   ` Juri Linkov
@ 2024-04-04  6:16   ` Juri Linkov
  2024-04-05 16:47     ` Juri Linkov
  1 sibling, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-04-04  6:16 UTC (permalink / raw)
  To: martin rudalics; +Cc: 69983

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





^ permalink raw reply related	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-04  6:16   ` Juri Linkov
@ 2024-04-05 16:47     ` Juri Linkov
  2024-04-06 18:42       ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-04-05 16:47 UTC (permalink / raw)
  To: martin rudalics; +Cc: 69983

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





^ permalink raw reply related	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-05 16:47     ` Juri Linkov
@ 2024-04-06 18:42       ` Juri Linkov
  2024-04-07  8:22         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-04-06 18:42 UTC (permalink / raw)
  To: martin rudalics; +Cc: 69983

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






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-06 18:42       ` Juri Linkov
@ 2024-04-07  8:22         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-09  6:30           ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-07  8:22 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-07  8:22         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-09  6:30           ` Juri Linkov
  2024-04-09  7:09             ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-04-09  6:30 UTC (permalink / raw)
  To: martin rudalics; +Cc: 69983

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





^ permalink raw reply related	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-09  6:30           ` Juri Linkov
@ 2024-04-09  7:09             ` Eli Zaretskii
  2024-04-09 16:34               ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2024-04-09  7:09 UTC (permalink / raw)
  To: Juri Linkov; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-09  7:09             ` Eli Zaretskii
@ 2024-04-09 16:34               ` Juri Linkov
  2024-04-09 18:28                 ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-04-09 16:34 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-09 16:34               ` Juri Linkov
@ 2024-04-09 18:28                 ` Eli Zaretskii
  2024-04-10  6:45                   ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2024-04-09 18:28 UTC (permalink / raw)
  To: Juri Linkov; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-09 18:28                 ` Eli Zaretskii
@ 2024-04-10  6:45                   ` Juri Linkov
  2024-04-10  8:47                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-10 11:07                     ` Eli Zaretskii
  0 siblings, 2 replies; 36+ messages in thread
From: Juri Linkov @ 2024-04-10  6:45 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-10  6:45                   ` Juri Linkov
@ 2024-04-10  8:47                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-10 11:07                     ` Eli Zaretskii
  1 sibling, 0 replies; 36+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-10  8:47 UTC (permalink / raw)
  To: Juri Linkov, Eli Zaretskii; +Cc: 69983

 > 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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-10  6:45                   ` Juri Linkov
  2024-04-10  8:47                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-10 11:07                     ` Eli Zaretskii
  2024-04-10 17:49                       ` Juri Linkov
  2024-04-11  9:16                       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 2 replies; 36+ messages in thread
From: Eli Zaretskii @ 2024-04-10 11:07 UTC (permalink / raw)
  To: Juri Linkov; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-10 11:07                     ` Eli Zaretskii
@ 2024-04-10 17:49                       ` Juri Linkov
  2024-04-10 18:13                         ` Eli Zaretskii
  2024-04-11  9:16                       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-04-10 17:49 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-10 17:49                       ` Juri Linkov
@ 2024-04-10 18:13                         ` Eli Zaretskii
  2024-04-11  6:31                           ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2024-04-10 18:13 UTC (permalink / raw)
  To: Juri Linkov; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-10 18:13                         ` Eli Zaretskii
@ 2024-04-11  6:31                           ` Juri Linkov
  2024-04-11  7:40                             ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-04-11  6:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-11  6:31                           ` Juri Linkov
@ 2024-04-11  7:40                             ` Eli Zaretskii
  2024-04-12  6:37                               ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2024-04-11  7:40 UTC (permalink / raw)
  To: Juri Linkov; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-10 11:07                     ` Eli Zaretskii
  2024-04-10 17:49                       ` Juri Linkov
@ 2024-04-11  9:16                       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-04-11 11:03                         ` Eli Zaretskii
  1 sibling, 1 reply; 36+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-11  9:16 UTC (permalink / raw)
  To: Eli Zaretskii, Juri Linkov; +Cc: 69983

 > 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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-11  9:16                       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-11 11:03                         ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2024-04-11 11:03 UTC (permalink / raw)
  To: martin rudalics; +Cc: 69983, juri

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-11  7:40                             ` Eli Zaretskii
@ 2024-04-12  6:37                               ` Juri Linkov
  2024-04-12  7:05                                 ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-04-12  6:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-12  6:37                               ` Juri Linkov
@ 2024-04-12  7:05                                 ` Eli Zaretskii
  2024-04-12 16:50                                   ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2024-04-12  7:05 UTC (permalink / raw)
  To: Juri Linkov; +Cc: rudalics, 69983

> 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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-12  7:05                                 ` Eli Zaretskii
@ 2024-04-12 16:50                                   ` Juri Linkov
  2024-04-12 18:27                                     ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2024-04-12 16:50 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#69983: Use category for display-buffer-alist
  2024-04-12 16:50                                   ` Juri Linkov
@ 2024-04-12 18:27                                     ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2024-04-12 18:27 UTC (permalink / raw)
  To: Juri Linkov; +Cc: rudalics, 69983

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2024-04-12 18:27 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-24 17:19 bug#69983: Use category for display-buffer-alist Juri Linkov
2024-03-25  9:41 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-25 17:12   ` Juri Linkov
2024-03-26  9:55     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27  7:15       ` Juri Linkov
2024-03-28  7:47         ` Juri Linkov
2024-03-28  8:23           ` Eli Zaretskii
2024-03-28 17:46             ` Juri Linkov
2024-03-28  9:18           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 17:50             ` Juri Linkov
2024-03-29  8:43               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-29 16:30                 ` Juri Linkov
2024-03-30  9:36                   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 18:22                     ` Juri Linkov
2024-04-02 16:52                       ` Juri Linkov
2024-04-04  6:16   ` Juri Linkov
2024-04-05 16:47     ` Juri Linkov
2024-04-06 18:42       ` Juri Linkov
2024-04-07  8:22         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-09  6:30           ` Juri Linkov
2024-04-09  7:09             ` Eli Zaretskii
2024-04-09 16:34               ` Juri Linkov
2024-04-09 18:28                 ` Eli Zaretskii
2024-04-10  6:45                   ` Juri Linkov
2024-04-10  8:47                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-10 11:07                     ` Eli Zaretskii
2024-04-10 17:49                       ` Juri Linkov
2024-04-10 18:13                         ` Eli Zaretskii
2024-04-11  6:31                           ` Juri Linkov
2024-04-11  7:40                             ` Eli Zaretskii
2024-04-12  6:37                               ` Juri Linkov
2024-04-12  7:05                                 ` Eli Zaretskii
2024-04-12 16:50                                   ` Juri Linkov
2024-04-12 18:27                                     ` Eli Zaretskii
2024-04-11  9:16                       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-11 11:03                         ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).