GNU bug report logs - #54296
Add buffer-matching functionality

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 54296 in the body.
You can then email your comments to 54296 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Add buffer-matching functionality
Date: Mon, 07 Mar 2022 22:33:29 +0000

[Message part 1 (text/plain, inline)]

Tags: patch


Project.el currently has a small language for matching buffers, used by
project-kill-buffers and project--read-project-buffer.  As mentioned in
[0], this could be generalised, as done in the patch below.  As to what
file this should be added to, should be discussed.

Either way I would consider these functions useful and would have wanted
to use them in my own code many times before.  While difficult, it might
also be useful for things like display-buffer-alist (the issue is that
a function as a condition in display-buffer-alist has to accept two
arguments, while the proposed patch only takes one).

To match functions such as string-match, the argument of buffer-match
could be reversed so that the function can be used as a testfn to
assoc/alist-get.

<tangent>
The reason this was not immediately done when project-kill-buffers was
implemented, was that this would raise the "emacs" dependency of the
ELPA package "project" to the latest release or even the current
development version.

To solve issues like these, I have been working on "compat", a
yet-unreleased library added to GNU ELPA a while back that could be
added as a dependency to project.  That way newer functions, such as the
ones propose below could be used, without breaking ELPA compatibility.

To make this work properly in the near future, compat would have to
follow the upstream development, before a release is made.  If there is
any interest in this kind of an arrangement, I could start a thread on
emacs-devel to discuss the details.
</tangent>

[0] https://mail.gnu.org/archive/html/emacs-devel/2020-09/msg00082.html
[1] https://elpa.gnu.org/devel/compat.html


In GNU Emacs 29.0.50 (build 13, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
 of 2022-02-24 built on viero
Repository revision: bd17fa2c7565f180cedbfa396c0b159e144178cb
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000

[0001-Generalise-buffer-matching-from-project.el.patch (text/patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
	Philip Kaludercic

Message #8 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 54296 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 09 Mar 2022 17:20:45 +0100

Philip Kaludercic <philipk <at> posteo.net> writes:

> Either way I would consider these functions useful and would have wanted
> to use them in my own code many times before.  While difficult, it might
> also be useful for things like display-buffer-alist (the issue is that
> a function as a condition in display-buffer-alist has to accept two
> arguments, while the proposed patch only takes one).

Hm...  how would this be used with display-buffer-alist, then?  (And
perhaps Martin has some comments; added to the CCs.)

> To match functions such as string-match, the argument of buffer-match
> could be reversed so that the function can be used as a testfn to
> assoc/alist-get.

I think I'd prefer to have the parameters reversed -- the condition is a
kind of predicate, and these days we seem to prefer to have the
predicate first.

> +(defun buffer-match (buffer condition)
> +  "Return non-nil if BUFFER matches CONDITION.
> +CONDITION is is either:
> +- a regular expression, to match a buffer name,
> +- a predicate function that takes a buffer object as argument
> +  and returns non-nil if the buffer should be killed,

Killed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Philip Kaludercic <philipk <at> posteo.net>
Cc: 54296 <at> debbugs.gnu.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 9 Mar 2022 21:34:19 +0100

>> Either way I would consider these functions useful and would have wanted
>> to use them in my own code many times before.  While difficult, it might
>> also be useful for things like display-buffer-alist (the issue is that
>> a function as a condition in display-buffer-alist has to accept two
>> arguments, while the proposed patch only takes one).
>
> Hm...  how would this be used with display-buffer-alist, then?  (And
> perhaps Martin has some comments; added to the CCs.)

Either add an optional second argument to 'buffer-match' or add to
'display-buffer-alist' an entry that uses a function as condition that
calls 'buffer-match' with the first argument and returns non-nil if
'buffer-match' reports a match.  I see no issue here.

martin

Message #14 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 54296 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Thu, 10 Mar 2022 10:05:04 +0000

[Message part 1 (text/plain, inline)]

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> Either way I would consider these functions useful and would have wanted
>> to use them in my own code many times before.  While difficult, it might
>> also be useful for things like display-buffer-alist (the issue is that
>> a function as a condition in display-buffer-alist has to accept two
>> arguments, while the proposed patch only takes one).
>
> Hm...  how would this be used with display-buffer-alist, then?  (And
> perhaps Martin has some comments; added to the CCs.)

See below.

>> To match functions such as string-match, the argument of buffer-match
>> could be reversed so that the function can be used as a testfn to
>> assoc/alist-get.
>
> I think I'd prefer to have the parameters reversed -- the condition is a
> kind of predicate, and these days we seem to prefer to have the
> predicate first.

I agree, it makes more sense.

>> +(defun buffer-match (buffer condition)
>> +  "Return non-nil if BUFFER matches CONDITION.
>> +CONDITION is is either:
>> +- a regular expression, to match a buffer name,
>> +- a predicate function that takes a buffer object as argument
>> +  and returns non-nil if the buffer should be killed,
>
> Killed?

That was a typo from copying the docstring.  Here is the updated patch:

[0001-Generalise-buffer-matching-from-project.el.patch (text/x-patch, inline)]

From 6714a4dc7168e6806dba0707c9c0b80d3365b2c5 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk <at> posteo.net>
Date: Mon, 7 Mar 2022 20:49:42 +0100
Subject: [PATCH 1/2] Generalise buffer matching from project.el

* subr.el (buffer-match): Add function to check if a buffer satisfies
a condition.
(match-buffers): Returns all buffers that satisfy a condition.
---
 lisp/subr.el | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 64 insertions(+)

diff --git a/lisp/subr.el b/lisp/subr.el
index 2321765f95..adcd25ec14 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -6613,4 +6613,68 @@ delete-line
                    (forward-line 1)
                    (point))))
 
+(defun buffer-match (condition buffer-or-name &optional arg)
+  "Return non-nil if BUFFER-OR-NAME matches CONDITION.
+CONDITION is is either:
+- a regular expression, to match a buffer name,
+- a predicate function that takes a buffer object and ARG as
+  arguments and returns non-nil if the buffer matches,
+- a cons-cell, where the car describes how to interpret the cdr.
+  The car can be one of the following:
+  * `major-mode': the buffer matches if the buffer's major
+    mode is eq to the cons-cell's cdr
+  * `derived-mode': the buffer matches if the buffer's major
+    mode is derived from the major mode denoted by the cons-cell's
+    cdr
+  * `not': the cdr is interpreted as a negation of a condition.
+  * `and': the cdr is a list of recursive condition, that all have
+    to be met.
+  * `or': the cdr is a list of recursive condition, of which at
+    least one has to be met."
+  (letrec
+      ((buffer (get-buffer buffer-or-name))
+       (match
+        (lambda (conditions)
+          (catch 'match
+            (dolist (condition conditions)
+              (when (cond
+                     ((stringp condition)
+                      (string-match-p condition (buffer-name buffer)))
+                     ((functionp condition)
+                      (if (eq 1 (cdr (func-arity condition)))
+                          (funcall condition buffer)
+                        (funcall condition buffer arg)))
+                     ((eq (car-safe condition) 'major-mode)
+                      (eq (buffer-local-value 'major-mode buffer)
+                          (cdr condition)))
+                     ((eq (car-safe condition) 'derived-mode)
+                      (provided-mode-derived-p
+                       (buffer-local-value 'major-mode buffer)
+                       (cdr condition)))
+                     ((eq (car-safe condition) 'not)
+                      (not (funcall match (cdr condition))))
+                     ((eq (car-safe condition) 'or)
+                      (funcall match (cdr condition)))
+                     ((eq (car-safe condition) 'and)
+                      (catch 'fail
+                        (dolist (c conditions)
+                          (unless (funcall match c)
+                            (throw 'fail nil)))
+                        t)))
+                (throw 'match t)))))))
+    (funcall match (list condition))))
+
+(defun match-buffers (condition &optional buffers arg)
+  "Return a list of buffers that match CONDITION.
+See `buffer-match' for details on CONDITION.  By default all
+buffers are checked, this can be restricted by passing an
+optional argument BUFFERS, set to a list of buffers to check.
+ARG is passed to `buffer-match', for predicate conditions in
+CONDITION."
+  (let (bufs)
+    (dolist (buf (or buffers (buffer-list)))
+      (when (buffer-match condition (get-buffer buf) arg)
+        (push buf bufs)))
+    bufs))
+
 ;;; subr.el ends here
-- 
2.34.0

[Message part 3 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> writes:

>>> Either way I would consider these functions useful and would have
>>> wanted
>>> to use them in my own code many times before.  While difficult, it
>>> might
>>> also be useful for things like display-buffer-alist (the issue is that
>>> a function as a condition in display-buffer-alist has to accept two
>>> arguments, while the proposed patch only takes one).
>>
>> Hm...  how would this be used with display-buffer-alist, then?  (And
>> perhaps Martin has some comments; added to the CCs.)
>
> Either add an optional second argument to 'buffer-match' or add to
> 'display-buffer-alist' an entry that uses a function as condition that
> calls 'buffer-match' with the first argument and returns non-nil if
> 'buffer-match' reports a match.  I see no issue here.

This seems to work, and updating window.el was also pretty trivial
(unless I have missed something):

[0002-window.el-display-buffer-assq-regexp-Use-buffer-matc.patch (text/x-patch, inline)]

From fadea32d0dc74952ca70f8d98ced59616c0e3e1a Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk <at> posteo.net>
Date: Thu, 10 Mar 2022 10:59:52 +0100
Subject: [PATCH 2/2] * window.el (display-buffer-assq-regexp): Use
 buffer-match

---
 lisp/window.el | 15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/lisp/window.el b/lisp/window.el
index 54c9eee5f3..4225019920 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -7497,19 +7497,12 @@ display-buffer-fallback-action
 (defun display-buffer-assq-regexp (buffer-name alist action)
   "Retrieve ALIST entry corresponding to BUFFER-NAME.
 This returns the cdr of the alist entry ALIST if either its key
-is a string that matches BUFFER-NAME, as reported by
-`string-match-p'; or if the key is a function that returns
-non-nil when called with three arguments: the ALIST key,
-BUFFER-NAME and ACTION.  ACTION should have the form of the
-action argument passed to `display-buffer'."
+satisfied a BUFFER-NAME per `buffer-match'.  ACTION should have
+the form of the action argument passed to `display-buffer'."
   (catch 'match
     (dolist (entry alist)
-      (let ((key (car entry)))
-	(when (or (and (stringp key)
-		       (string-match-p key buffer-name))
-		  (and (functionp key)
-		       (funcall key buffer-name action)))
-	  (throw 'match (cdr entry)))))))
+      (when (buffer-match (car entry) buffer-name action)
+        (throw 'match (cdr entry))))))
 
 (defvar display-buffer--same-window-action
   '(display-buffer-same-window
-- 
2.34.0

[Message part 5 (text/plain, inline)]

> martin
>

-- 
	Philip Kaludercic

Message #17 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Thu, 10 Mar 2022 13:53:54 +0200

> From: Philip Kaludercic <philipk <at> posteo.net>
> Date: Thu, 10 Mar 2022 10:05:04 +0000
> Cc: 54296 <at> debbugs.gnu.org
> 
> +(defun buffer-match (condition buffer-or-name &optional arg)
> +  "Return non-nil if BUFFER-OR-NAME matches CONDITION.

This is a predicate function, so its name should be buffer-matches-p
or maybe buffer-matches-condition-p.

> +CONDITION is is either:
             ^^^^^
Typo.

> +- a regular expression, to match a buffer name,
> +- a predicate function that takes a buffer object and ARG as
> +  arguments and returns non-nil if the buffer matches,
              ^
Comma missing there.

> +- a cons-cell, where the car describes how to interpret the cdr.
> +  The car can be one of the following:
> +  * `major-mode': the buffer matches if the buffer's major
> +    mode is eq to the cons-cell's cdr
> +  * `derived-mode': the buffer matches if the buffer's major
> +    mode is derived from the major mode denoted by the cons-cell's
> +    cdr

Do we really need both major-mode and derived-mode?

> +  * `not': the cdr is interpreted as a negation of a condition.
> +  * `and': the cdr is a list of recursive condition, that all have
> +    to be met.                            ^^^^^^^^^

Typo: should be "conditions".

> +  * `or': the cdr is a list of recursive condition, of which at
> +    least one has to be met."            ^^^^^^^^^

Likewise.

Thanks.

Message #20 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Thu, 10 Mar 2022 12:13:59 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Date: Thu, 10 Mar 2022 10:05:04 +0000
>> Cc: 54296 <at> debbugs.gnu.org
>> 
>> +(defun buffer-match (condition buffer-or-name &optional arg)
>> +  "Return non-nil if BUFFER-OR-NAME matches CONDITION.
>
> This is a predicate function, so its name should be buffer-matches-p
> or maybe buffer-matches-condition-p.

I like buffer-matches-p.

>> +CONDITION is is either:
>              ^^^^^
> Typo.

Sorry about those, it and the other ones here:

[0001-Generalise-buffer-matching-from-project.el.patch (text/x-patch, inline)]

From 8dfcabb8c655f06c8c7285c6da7efad7057b636e Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk <at> posteo.net>
Date: Mon, 7 Mar 2022 20:49:42 +0100
Subject: [PATCH 1/2] Generalise buffer matching from project.el

* subr.el (buffer-match): Add function to check if a buffer satisfies
a condition.
(match-buffers): Returns all buffers that satisfy a condition.
---
 lisp/subr.el | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 64 insertions(+)

diff --git a/lisp/subr.el b/lisp/subr.el
index 2321765f95..e55a4c5802 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -6613,4 +6613,68 @@ delete-line
                    (forward-line 1)
                    (point))))
 
+(defun buffer-match-p (condition buffer-or-name &optional arg)
+  "Return non-nil if BUFFER-OR-NAME matches CONDITION.
+CONDITION is either:
+- a regular expression, to match a buffer name,
+- a predicate function that takes a buffer object and ARG as
+  arguments, and returns non-nil if the buffer matches,
+- a cons-cell, where the car describes how to interpret the cdr.
+  The car can be one of the following:
+  * `major-mode': the buffer matches if the buffer's major
+    mode is eq to the cons-cell's cdr
+  * `derived-mode': the buffer matches if the buffer's major
+    mode is derived from the major mode denoted by the cons-cell's
+    cdr
+  * `not': the cdr is interpreted as a negation of a condition.
+  * `and': the cdr is a list of recursive conditions, that all have
+    to be met.
+  * `or': the cdr is a list of recursive condition, of which at
+    least one has to be met."
+  (letrec
+      ((buffer (get-buffer buffer-or-name))
+       (match
+        (lambda (conditions)
+          (catch 'match
+            (dolist (condition conditions)
+              (when (cond
+                     ((stringp condition)
+                      (string-match-p condition (buffer-name buffer)))
+                     ((functionp condition)
+                      (if (eq 1 (cdr (func-arity condition)))
+                          (funcall condition buffer)
+                        (funcall condition buffer arg)))
+                     ((eq (car-safe condition) 'major-mode)
+                      (eq (buffer-local-value 'major-mode buffer)
+                          (cdr condition)))
+                     ((eq (car-safe condition) 'derived-mode)
+                      (provided-mode-derived-p
+                       (buffer-local-value 'major-mode buffer)
+                       (cdr condition)))
+                     ((eq (car-safe condition) 'not)
+                      (not (funcall match (cdr condition))))
+                     ((eq (car-safe condition) 'or)
+                      (funcall match (cdr condition)))
+                     ((eq (car-safe condition) 'and)
+                      (catch 'fail
+                        (dolist (c conditions)
+                          (unless (funcall match c)
+                            (throw 'fail nil)))
+                        t)))
+                (throw 'match t)))))))
+    (funcall match (list condition))))
+
+(defun match-buffers (condition &optional buffers arg)
+  "Return a list of buffers that match CONDITION.
+See `buffer-match' for details on CONDITION.  By default all
+buffers are checked, this can be restricted by passing an
+optional argument BUFFERS, set to a list of buffers to check.
+ARG is passed to `buffer-match', for predicate conditions in
+CONDITION."
+  (let (bufs)
+    (dolist (buf (or buffers (buffer-list)))
+      (when (buffer-match-p condition (get-buffer buf) arg)
+        (push buf bufs)))
+    bufs))
+
 ;;; subr.el ends here
-- 
2.34.0

[Message part 3 (text/plain, inline)]

>> +- a cons-cell, where the car describes how to interpret the cdr.
>> +  The car can be one of the following:
>> +  * `major-mode': the buffer matches if the buffer's major
>> +    mode is eq to the cons-cell's cdr
>> +  * `derived-mode': the buffer matches if the buffer's major
>> +    mode is derived from the major mode denoted by the cons-cell's
>> +    cdr
>
> Do we really need both major-mode and derived-mode?

It seems to have been useful in project.el, see
`project-kill-buffer-conditions'.  In that case you want to both be able
to say something like "kill buffers only if they are in
fundamental-mode", but also something like "kill all buffers that are
based on comint-mode".

-- 
	Philip Kaludercic

Message #23 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: "54296 <at> debbugs.gnu.org" <54296 <at> debbugs.gnu.org>,
 "larsi <at> gnus.org" <larsi <at> gnus.org>
Subject: RE: [External] : bug#54296: Add buffer-matching functionality
Date: Thu, 10 Mar 2022 14:52:46 +0000

> > This is a predicate function, so its name should be buffer-matches-p
> > or maybe buffer-matches-condition-p.
> 
> I like buffer-matches-p.

(I'm not following this thread, BTW.)

"Matching" typically has a connotation of pattern
matching.  In the case of Emacs it is especially
about textual patterns matching text.

If you're testing a buffer object, and not just
its text or its name, then it's probably better
to speak of the buffer "satisfying" a condition
or a predicate than it is to speak of it
"matching" a condition or a predicate.

In general, patterns are matched; conditions and
predicates are satisfied.

Message #26 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Philip Kaludercic <philipk <at> posteo.net>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 54296 <at> debbugs.gnu.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Thu, 10 Mar 2022 16:42:25 +0100

> This seems to work, and updating window.el was also pretty trivial
> (unless I have missed something):

IIUC the doc-string would now say that

  This returns the cdr of the alist entry ALIST if either its key
  satisfied a BUFFER-NAME per `buffer-match'.

which doesn't appear correct.  In either case please make sure that your
change does not affect existing behavior where a buffer is not displayed
in a specific way because it does not match 'display-buffer-assq-regexp'
until now.

Thanks, martin

Message #29 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Thu, 10 Mar 2022 18:56:18 +0200

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
> Date: Thu, 10 Mar 2022 12:13:59 +0000
> 
> > Do we really need both major-mode and derived-mode?
> 
> It seems to have been useful in project.el, see
> `project-kill-buffer-conditions'.  In that case you want to both be able
> to say something like "kill buffers only if they are in
> fundamental-mode", but also something like "kill all buffers that are
> based on comint-mode".

So this is only because of fundamental-mode?  If so, shouldn't it be
enough to have a possibility to have a predicate function, which can
do anything one likes?

I think we want in general avoid comparison with major-mode, and
prefer derived-mode instead, and if so, IMO we had better did as we
say and not exposed comparison to major mode unless we absolutely
must.

Message #32 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Fri, 11 Mar 2022 16:21:06 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
>> Date: Thu, 10 Mar 2022 12:13:59 +0000
>> 
>> > Do we really need both major-mode and derived-mode?
>> 
>> It seems to have been useful in project.el, see
>> `project-kill-buffer-conditions'.  In that case you want to both be able
>> to say something like "kill buffers only if they are in
>> fundamental-mode", but also something like "kill all buffers that are
>> based on comint-mode".
>
> So this is only because of fundamental-mode?

I wouldn't say so, that is a known use-case, that is one I know of right
now, but there is no reason something like that couldn't come up again?

> If so, shouldn't it be enough to have a possibility to have a
> predicate function, which can do anything one likes?

Everything this patch introduces could be replace by a predicate, but
the other issue is that if the major-mode/derived-mode distinction is
removed the function couldn't be used in project.el anymore, or would
have to break compatibility.

> I think we want in general avoid comparison with major-mode, and
> prefer derived-mode instead, and if so, IMO we had better did as we
> say and not exposed comparison to major mode unless we absolutely
> must.

Would it be enough to clarify this point in the documentation string?

-- 
	Philip Kaludercic

Message #35 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Fri, 11 Mar 2022 20:34:01 +0200

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
> Date: Fri, 11 Mar 2022 16:21:06 +0000
> 
> > I think we want in general avoid comparison with major-mode, and
> > prefer derived-mode instead, and if so, IMO we had better did as we
> > say and not exposed comparison to major mode unless we absolutely
> > must.
> 
> Would it be enough to clarify this point in the documentation string?

What would you like to clarify?

Message #38 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 larsi <at> gnus.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Sat, 12 Mar 2022 11:23:22 +0100

Coincidentally, I've been discussing with Stefan a similar mini-language
for the 'font-lock-ignore' feature.  Here are some thoughts

On Thu, 10 Mar 2022 at 13:53, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> +- a cons-cell, where the car describes how to interpret the cdr.
>> +  The car can be one of the following:
>> +  * `major-mode': the buffer matches if the buffer's major
>> +    mode is eq to the cons-cell's cdr
>> +  * `derived-mode': the buffer matches if the buffer's major
>> +    mode is derived from the major mode denoted by the cons-cell's
>> +    cdr
>
> Do we really need both major-mode and derived-mode?

It seems handy to allow (mode MODE) to match a buffer with major mode
derived from MODE or if MODE is bound and true as a variable in that
buffer (say, it's the name of a minor mode).

>> +  * `not': the cdr is interpreted as a negation of a condition.
>> +  * `and': the cdr is a list of recursive condition, that all have
>> +    to be met.                            ^^^^^^^^^
>
> Typo: should be "conditions".
>
>> +  * `or': the cdr is a list of recursive condition, of which at
>> +    least one has to be met."            ^^^^^^^^^

In 'font-lock-ignore' you can prefix an or-condition with !, with the
gitignore semantics.  This seems very appropriate for a buffer-matching
functionality.

But then `or' is not the familiar short-circuiting
operation, and you need to evaluate the conditions backwards...

On a more bikesheddy note, I'm also debating a bit what is more
readable:

    (or cond1 cond2 ! cond2)

or else
  
    (or cond1 cond2 (except cond2))

Message #41 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 54296 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Sat, 12 Mar 2022 11:07:51 +0000

Augusto Stoffel <arstoffel <at> gmail.com> writes:

>>> +  * `not': the cdr is interpreted as a negation of a condition.
>>> +  * `and': the cdr is a list of recursive condition, that all have
>>> +    to be met.                            ^^^^^^^^^
>>
>> Typo: should be "conditions".
>>
>>> +  * `or': the cdr is a list of recursive condition, of which at
>>> +    least one has to be met."            ^^^^^^^^^
>
> In 'font-lock-ignore' you can prefix an or-condition with !, with the
> gitignore semantics.  This seems very appropriate for a buffer-matching
> functionality.
>
> But then `or' is not the familiar short-circuiting
> operation, and you need to evaluate the conditions backwards...
>
> On a more bikesheddy note, I'm also debating a bit what is more
> readable:
>
>     (or cond1 cond2 ! cond2)
>
> or else
>   
>     (or cond1 cond2 (except cond2))

If this would be included, I would certainly prefer the latter.

-- 
	Philip Kaludercic

Message #44 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Sun, 13 Mar 2022 20:40:49 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
>> Date: Fri, 11 Mar 2022 16:21:06 +0000
>> 
>> > I think we want in general avoid comparison with major-mode, and
>> > prefer derived-mode instead, and if so, IMO we had better did as we
>> > say and not exposed comparison to major mode unless we absolutely
>> > must.
>> 
>> Would it be enough to clarify this point in the documentation string?
>
> What would you like to clarify?

To clarify that the usage of (major-mode . foo-mode) might not be what
the user intends, and that in most cases derived-mode is preferable.

-- 
	Philip Kaludercic

Message #47 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Mon, 14 Mar 2022 05:21:47 +0200

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
> Date: Sun, 13 Mar 2022 20:40:49 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Philip Kaludercic <philipk <at> posteo.net>
> >> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
> >> Date: Fri, 11 Mar 2022 16:21:06 +0000
> >> 
> >> > I think we want in general avoid comparison with major-mode, and
> >> > prefer derived-mode instead, and if so, IMO we had better did as we
> >> > say and not exposed comparison to major mode unless we absolutely
> >> > must.
> >> 
> >> Would it be enough to clarify this point in the documentation string?
> >
> > What would you like to clarify?
> 
> To clarify that the usage of (major-mode . foo-mode) might not be what
> the user intends, and that in most cases derived-mode is preferable.

I suggested to "clarify" that by not providing the 'major-mode'
predicate at all.  I still don't think I understand why it is so
important that we should provide a special case for it.

Message #50 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Mon, 14 Mar 2022 08:21:56 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
>> Date: Sun, 13 Mar 2022 20:40:49 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Philip Kaludercic <philipk <at> posteo.net>
>> >> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
>> >> Date: Fri, 11 Mar 2022 16:21:06 +0000
>> >> 
>> >> > I think we want in general avoid comparison with major-mode, and
>> >> > prefer derived-mode instead, and if so, IMO we had better did as we
>> >> > say and not exposed comparison to major mode unless we absolutely
>> >> > must.
>> >> 
>> >> Would it be enough to clarify this point in the documentation string?
>> >
>> > What would you like to clarify?
>> 
>> To clarify that the usage of (major-mode . foo-mode) might not be what
>> the user intends, and that in most cases derived-mode is preferable.
>
> I suggested to "clarify" that by not providing the 'major-mode'
> predicate at all.  I still don't think I understand why it is so
> important that we should provide a special case for it.

It is not inherently important, it is just that if the predicate would
also be used in project.el, then compatibility would have to be broken,
as the distinction between `major-mode' and `derived-mode' exists there.

-- 
	Philip Kaludercic

Message #53 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Mon, 14 Mar 2022 15:00:20 +0200

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
> Date: Mon, 14 Mar 2022 08:21:56 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Philip Kaludercic <philipk <at> posteo.net>
> >> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
> >> Date: Sun, 13 Mar 2022 20:40:49 +0000
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> >> From: Philip Kaludercic <philipk <at> posteo.net>
> >> >> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
> >> >> Date: Fri, 11 Mar 2022 16:21:06 +0000
> >> >> 
> >> >> > I think we want in general avoid comparison with major-mode, and
> >> >> > prefer derived-mode instead, and if so, IMO we had better did as we
> >> >> > say and not exposed comparison to major mode unless we absolutely
> >> >> > must.
> >> >> 
> >> >> Would it be enough to clarify this point in the documentation string?
> >> >
> >> > What would you like to clarify?
> >> 
> >> To clarify that the usage of (major-mode . foo-mode) might not be what
> >> the user intends, and that in most cases derived-mode is preferable.
> >
> > I suggested to "clarify" that by not providing the 'major-mode'
> > predicate at all.  I still don't think I understand why it is so
> > important that we should provide a special case for it.
> 
> It is not inherently important, it is just that if the predicate would
> also be used in project.el, then compatibility would have to be broken,
> as the distinction between `major-mode' and `derived-mode' exists there.

Then project.el could use the predicate route, right?  It's quite a
special case, AFAIU, so having a special solution is OK.

Message #56 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Mon, 14 Mar 2022 13:38:49 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
>> Date: Mon, 14 Mar 2022 08:21:56 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Philip Kaludercic <philipk <at> posteo.net>
>> >> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
>> >> Date: Sun, 13 Mar 2022 20:40:49 +0000
>> >> 
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> 
>> >> >> From: Philip Kaludercic <philipk <at> posteo.net>
>> >> >> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
>> >> >> Date: Fri, 11 Mar 2022 16:21:06 +0000
>> >> >> 
>> >> >> > I think we want in general avoid comparison with major-mode, and
>> >> >> > prefer derived-mode instead, and if so, IMO we had better did as we
>> >> >> > say and not exposed comparison to major mode unless we absolutely
>> >> >> > must.
>> >> >> 
>> >> >> Would it be enough to clarify this point in the documentation string?
>> >> >
>> >> > What would you like to clarify?
>> >> 
>> >> To clarify that the usage of (major-mode . foo-mode) might not be what
>> >> the user intends, and that in most cases derived-mode is preferable.
>> >
>> > I suggested to "clarify" that by not providing the 'major-mode'
>> > predicate at all.  I still don't think I understand why it is so
>> > important that we should provide a special case for it.
>> 
>> It is not inherently important, it is just that if the predicate would
>> also be used in project.el, then compatibility would have to be broken,
>> as the distinction between `major-mode' and `derived-mode' exists there.
>
> Then project.el could use the predicate route, right?  It's quite a
> special case, AFAIU, so having a special solution is OK.

The issue isn't that the default value couldn't be updated, but that if
anyone has e.g. been using `project-kill-buffer-conditions' over the
last 1½ years and has relied on the specific distinction between
`major-mode' and `derived-mode', they would run in to unexpected
results, that might result in more buffers being killed than intended,
potentially data being lost that the user might not expect because of an
update.

-- 
	Philip Kaludercic

Message #59 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Thu, 14 Apr 2022 08:25:58 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
>> Date: Mon, 14 Mar 2022 08:21:56 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Philip Kaludercic <philipk <at> posteo.net>
>> >> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
>> >> Date: Sun, 13 Mar 2022 20:40:49 +0000
>> >> 
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> 
>> >> >> From: Philip Kaludercic <philipk <at> posteo.net>
>> >> >> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
>> >> >> Date: Fri, 11 Mar 2022 16:21:06 +0000
>> >> >> 
>> >> >> > I think we want in general avoid comparison with major-mode, and
>> >> >> > prefer derived-mode instead, and if so, IMO we had better
>> >> >> > did as we
>> >> >> > say and not exposed comparison to major mode unless we
>> >> >> > absolutely
>> >> >> > must.
>> >> >> 
>> >> >> Would it be enough to clarify this point in the documentation
>> >> >> string?
>> >> >
>> >> > What would you like to clarify?
>> >> 
>> >> To clarify that the usage of (major-mode . foo-mode) might not be
>> >> what
>> >> the user intends, and that in most cases derived-mode is preferable.
>> >
>> > I suggested to "clarify" that by not providing the 'major-mode'
>> > predicate at all.  I still don't think I understand why it is so
>> > important that we should provide a special case for it.
>> 
>> It is not inherently important, it is just that if the predicate would
>> also be used in project.el, then compatibility would have to be broken,
>> as the distinction between `major-mode' and `derived-mode' exists there.
>
> Then project.el could use the predicate route, right?  It's quite a
> special case, AFAIU, so having a special solution is OK.

I have updated the commits as you recommended, and add a commit
deprecating the use of `derived-mode' in project.el.

-- 
	Philip Kaludercic

[0001-Generalise-buffer-matching-from-project.el.patch (text/x-patch, attachment)]

[0002-window.el-display-buffer-assq-regexp-Use-buffer-matc.patch (text/x-patch, attachment)]

[0003-Update-project-kill-buffer-conditions-to-match-buffe.patch (text/x-patch, attachment)]

Message #62 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Fri, 15 Apr 2022 09:56:04 +0300

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
> Date: Thu, 14 Apr 2022 08:25:58 +0000
> 
> >> > I suggested to "clarify" that by not providing the 'major-mode'
> >> > predicate at all.  I still don't think I understand why it is so
> >> > important that we should provide a special case for it.
> >> 
> >> It is not inherently important, it is just that if the predicate would
> >> also be used in project.el, then compatibility would have to be broken,
> >> as the distinction between `major-mode' and `derived-mode' exists there.
> >
> > Then project.el could use the predicate route, right?  It's quite a
> > special case, AFAIU, so having a special solution is OK.
> 
> I have updated the commits as you recommended, and add a commit
> deprecating the use of `derived-mode' in project.el.

Thanks, LGTM.

Message #67 received at 54296-done <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 54296-done <at> debbugs.gnu.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Fri, 15 Apr 2022 10:57:02 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
>> Date: Thu, 14 Apr 2022 08:25:58 +0000
>> 
>> >> > I suggested to "clarify" that by not providing the 'major-mode'
>> >> > predicate at all.  I still don't think I understand why it is so
>> >> > important that we should provide a special case for it.
>> >> 
>> >> It is not inherently important, it is just that if the predicate would
>> >> also be used in project.el, then compatibility would have to be broken,
>> >> as the distinction between `major-mode' and `derived-mode' exists there.
>> >
>> > Then project.el could use the predicate route, right?  It's quite a
>> > special case, AFAIU, so having a special solution is OK.
>> 
>> I have updated the commits as you recommended, and add a commit
>> deprecating the use of `derived-mode' in project.el.
>
> Thanks, LGTM.

Great!  The commits have been pushed.

-- 
	Philip Kaludercic

Message #74 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Mon, 13 Jun 2022 03:30:18 +0300

On 14.03.2022 15:38, Philip Kaludercic wrote:
> The issue isn't that the default value couldn't be updated, but that if
> anyone has e.g. been using `project-kill-buffer-conditions' over the
> last 1½ years and has relied on the specific distinction between
> `major-mode' and `derived-mode', they would run in to unexpected
> results, that might result in more buffers being killed than intended,
> potentially data being lost that the user might not expect because of an
> update.

I see that this point hasn't been addressed at all.

Eli?

Message #77 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Philip Kaludercic <philipk <at> posteo.net>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Mon, 13 Jun 2022 03:30:25 +0300

On 14.03.2022 05:21, Eli Zaretskii wrote:
> I still don't think I understand why it is so
> important that we should provide a special case for it.

It's pretty valuable to be able to provide a default value of 
project-kill-buffer-conditions which can be read at a glance (including 
in compiled Emacs) and easily edited via customize-variable by a user 
with little to no knowledge of Elisp.

And 'major-mode' was used twice inside project-kill-buffer-conditions, 
not just once.

Message #80 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Mon, 13 Jun 2022 15:04:58 +0300

> Date: Mon, 13 Jun 2022 03:21:13 +0300
> Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 14.03.2022 15:38, Philip Kaludercic wrote:
> > The issue isn't that the default value couldn't be updated, but that if
> > anyone has e.g. been using `project-kill-buffer-conditions' over the
> > last 1½ years and has relied on the specific distinction between
> > `major-mode' and `derived-mode', they would run in to unexpected
> > results, that might result in more buffers being killed than intended,
> > potentially data being lost that the user might not expect because of an
> > update.
> 
> I see that this point hasn't been addressed at all.
> 
> Eli?

Do you agree with Philip that deprecating or removing major-mode would
be a problem for users of project-kill-buffer-conditions etc.?

I kinda gave up because Philip felt extremely uneasy with dropping
major-mode, leaving us with just derived-mode, but I still think we
shouldn't encourage Lisp programs to use major-mode.  So if you don't
think it would be a problem, I'd be happier if we removed major-mode
and used derived-mode instead.

Message #83 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Mon, 13 Jun 2022 15:13:18 +0300

> Date: Mon, 13 Jun 2022 03:23:47 +0300
> Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 14.03.2022 05:21, Eli Zaretskii wrote:
> > I still don't think I understand why it is so
> > important that we should provide a special case for it.
> 
> It's pretty valuable to be able to provide a default value of 
> project-kill-buffer-conditions which can be read at a glance (including 
> in compiled Emacs) and easily edited via customize-variable by a user 
> with little to no knowledge of Elisp.
> 
> And 'major-mode' was used twice inside project-kill-buffer-conditions, 
> not just once.

I think I lost context, so please bear with me.

My "still don't think I understand" comment was about the need to
support major-mode when apparently the _only_ user of that is
fundamental-mode, where we cannot use derived-mode instead.  If indeed
fundamental-mode is the only case where major-mode is useful, I asked
why not use a predicate that tests explicitly for that case.

And if I understand your reasoning above, then doesn't

  (eq major-mode 'fundamental-mode)

provide an easy default that can be read at a glance?

Or what am I missing?

Message #86 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Tue, 14 Jun 2022 21:43:41 +0300

On 13.06.2022 15:04, Eli Zaretskii wrote:
>> Date: Mon, 13 Jun 2022 03:21:13 +0300
>> Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> On 14.03.2022 15:38, Philip Kaludercic wrote:
>>> The issue isn't that the default value couldn't be updated, but that if
>>> anyone has e.g. been using `project-kill-buffer-conditions' over the
>>> last 1½ years and has relied on the specific distinction between
>>> `major-mode' and `derived-mode', they would run in to unexpected
>>> results, that might result in more buffers being killed than intended,
>>> potentially data being lost that the user might not expect because of an
>>> update.
>>
>> I see that this point hasn't been addressed at all.
>>
>> Eli?
> 
> Do you agree with Philip that deprecating or removing major-mode would
> be a problem for users of project-kill-buffer-conditions etc.?

Yes. I also mentioned that here: 
https://lists.gnu.org/archive/html/emacs-devel/2022-06/msg00650.html

Not for all users, only for some of those who customized the value, 
etc... but we're usually more concerned about backward compatibility 
than the present development seems to have indicated.

If we can argue over several days (or weeks?) about removing a key 
binding that nobody uses, changing DSL in an incompatible way has to be 
considered a problem.

> I kinda gave up because Philip felt extremely uneasy with dropping
> major-mode, leaving us with just derived-mode, but I still think we
> shouldn't encourage Lisp programs to use major-mode.  So if you don't
> think it would be a problem, I'd be happier if we removed major-mode
> and used derived-mode instead.

If I didn't think Philip's point had merit, I wouldn't have brought it 
up now.

The idea of discouraging the (eq major-mode ...) semantics (instead of 
derived-mode-p) has merit, but so far we have one complex prior art for 
this functionality, and it did find a use for this distinction. Two 
uses, to be exact.

Another example where we might migrate to buffer-matches-p is 
'turn-on-font-lock-if-desired'. And that one also currently uses

  (memq major-mode font-lock-global-modes)

rather than derived-mode-p. There probably are reasons for this as well.

We could try some methods that discourage the use of 'major-mode' as 
opposed to 'derived-mode'. Maybe by calling them 'major-mode-eq' and 
'major-mode' (where the longer version feels more awkward and thus less 
desirable). But FWIW I like the current couple of 'derived-mode' and 
'major-mode' because it feels "transparent" for an experienced Elisp 
programmer. Rather than having one guess that 'major-mode' uses the 
derived-mode-p predicate or search for that info in the docs.

And if we change the keywords in project-kill-buffer-conditions, I 
suppose it will require some migration strategy. Which is going to be a 
pain.

Message #89 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Tue, 14 Jun 2022 21:47:53 +0300

> Date: Tue, 14 Jun 2022 21:43:41 +0300
> Cc: philipk <at> posteo.net, 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 13.06.2022 15:04, Eli Zaretskii wrote:
> >> Date: Mon, 13 Jun 2022 03:21:13 +0300
> >> Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
> >> From: Dmitry Gutov <dgutov <at> yandex.ru>
> >>
> >> On 14.03.2022 15:38, Philip Kaludercic wrote:
> >>> The issue isn't that the default value couldn't be updated, but that if
> >>> anyone has e.g. been using `project-kill-buffer-conditions' over the
> >>> last 1½ years and has relied on the specific distinction between
> >>> `major-mode' and `derived-mode', they would run in to unexpected
> >>> results, that might result in more buffers being killed than intended,
> >>> potentially data being lost that the user might not expect because of an
> >>> update.
> >>
> >> I see that this point hasn't been addressed at all.
> >>
> >> Eli?
> > 
> > Do you agree with Philip that deprecating or removing major-mode would
> > be a problem for users of project-kill-buffer-conditions etc.?
> 
> Yes. I also mentioned that here: 
> https://lists.gnu.org/archive/html/emacs-devel/2022-06/msg00650.html

So then everything is okay, AFAIU, because eventually Philip left that
in the code.  Right?

> > I kinda gave up because Philip felt extremely uneasy with dropping
> > major-mode, leaving us with just derived-mode, but I still think we
> > shouldn't encourage Lisp programs to use major-mode.  So if you don't
> > think it would be a problem, I'd be happier if we removed major-mode
> > and used derived-mode instead.
> 
> If I didn't think Philip's point had merit, I wouldn't have brought it 
> up now.

OK, but I didn't press my POV, so where's the problem, and why the
emotions?

Message #92 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Tue, 14 Jun 2022 22:00:20 +0300

On 13.06.2022 15:13, Eli Zaretskii wrote:
> My "still don't think I understand" comment was about the need to
> support major-mode when apparently the_only_  user of that is
> fundamental-mode, where we cannot use derived-mode instead.

There are two uses of it inside project-kill-buffer-conditions.

One is

  (major-mode . fundamental-mode)

, and another is

  (and (derived-mode . special-mode)
         (not (major-mode . help-mode)))

I suppose in the latter it doesn't really matter whether the check uses 
'derived-mode-p', but the current way is more conservative.

Also see the turn-on-font-lock-if-desired example from the other email.

> If indeed
> fundamental-mode is the only case where major-mode is useful, I asked
> why not use a predicate that tests explicitly for that case.

If a predicate is a lambda, then it's not as readable.

> And if I understand your reasoning above, then doesn't
> 
>    (eq major-mode 'fundamental-mode)
> 
> provide an easy default that can be read at a glance?

Are you proposing adding a "keyword" 'eq' which would have a variable 
name as its first arg and the value as its second arg?

That would work (aside from the backward compatibility concerns). It 
might look confusing to a Lisp programmer, resembling "regular" code too 
much, creating false expectations.

Message #95 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Tue, 14 Jun 2022 22:17:16 +0300

> Date: Tue, 14 Jun 2022 22:00:20 +0300
> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> > And if I understand your reasoning above, then doesn't
> > 
> >    (eq major-mode 'fundamental-mode)
> > 
> > provide an easy default that can be read at a glance?
> 
> Are you proposing adding a "keyword" 'eq' which would have a variable 
> name as its first arg and the value as its second arg?

No, I proposed to use the "predicate function" method (which already
exists).

Message #98 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Tue, 14 Jun 2022 22:36:55 +0300

On 14.06.2022 21:47, Eli Zaretskii wrote:

>>> Do you agree with Philip that deprecating or removing major-mode would
>>> be a problem for users of project-kill-buffer-conditions etc.?
>>
>> Yes. I also mentioned that here:
>> https://lists.gnu.org/archive/html/emacs-devel/2022-06/msg00650.html
> 
> So then everything is okay, AFAIU, because eventually Philip left that
> in the code.  Right?

No, he didn't.

He tried to migrate project-kill-buffer-conditions to the new format, 
with predicted unfortunate side-effects. And an unpredicted one (which 
is easier to fix, though).

See commit 1a3bad431d.

>>> I kinda gave up because Philip felt extremely uneasy with dropping
>>> major-mode, leaving us with just derived-mode, but I still think we
>>> shouldn't encourage Lisp programs to use major-mode.  So if you don't
>>> think it would be a problem, I'd be happier if we removed major-mode
>>> and used derived-mode instead.
>>
>> If I didn't think Philip's point had merit, I wouldn't have brought it
>> up now.
> 
> OK, but I didn't press my POV, so where's the problem, and why the
> emotions?

Your POV was the one that got implemented. buffer-match-p has 
'major-mode' but not 'derived-mode'. And 'major-mode' behaves like 
'derived-mode' behaved in project-kill-buffer-conditions.

Message #101 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Tue, 14 Jun 2022 22:46:49 +0300

On 14.06.2022 22:17, Eli Zaretskii wrote:
> No, I proposed to use the "predicate function" method (which already
> exists).

Then the downside is "it's not readable". Or editable, really.

At this point you could say that we need to support lambas anyway (ok), 
and if people use them, we can use it for this purpose too.

But it seems to me that, by not supporting lambdas so far, over the 
couple of years since its introduction, project-kill-buffer-conditions 
has kind of proven its minimal DSL to be viable.

And if by having the 'major-mode eq' matcher we manage to avoid the use 
of lambdas in 99%+ use cases, then that's a win for usability.

Message #104 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 15 Jun 2022 05:33:14 +0300

> Date: Tue, 14 Jun 2022 22:36:55 +0300
> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 14.06.2022 21:47, Eli Zaretskii wrote:
> 
> > So then everything is okay, AFAIU, because eventually Philip left that
> > in the code.  Right?
> 
> No, he didn't.
> 
> He tried to migrate project-kill-buffer-conditions to the new format, 
> with predicted unfortunate side-effects. And an unpredicted one (which 
> is easier to fix, though).
> 
> See commit 1a3bad431d.

Which part?

AFAICT, major-mode is still in the code:

  (defun buffer-match-p (condition buffer-or-name &optional arg)
    "Return non-nil if BUFFER-OR-NAME matches CONDITION.
  CONDITION is either:
  - a regular expression, to match a buffer name,
  - a predicate function that takes a buffer object and ARG as
    arguments, and returns non-nil if the buffer matches,
  - a cons-cell, where the car describes how to interpret the cdr.
    The car can be one of the following:
    * `major-mode': the buffer matches if the buffer's major
      mode is derived from the major mode denoted by the cons-cell's
      cdr
  [...]
		       ((eq (car-safe condition) 'major-mode)
			(provided-mode-derived-p
			 (buffer-local-value 'major-mode buffer)
			 (cdr condition)))


> > OK, but I didn't press my POV, so where's the problem, and why the
> > emotions?
> 
> Your POV was the one that got implemented. buffer-match-p has 
> 'major-mode' but not 'derived-mode'. And 'major-mode' behaves like 
> 'derived-mode' behaved in project-kill-buffer-conditions.

This seems to be some misunderstanding.  I wanted us to have only
'derived-mode', not 'major-mode'.  But Philip was unhappy about that,
due to existing usage of 'major-mode', and eventually 'major-mode' was
left in the code.  Or at least this is my recollection of the
discussion and its resolution.

Message #107 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 15 Jun 2022 05:34:33 +0300

> Date: Tue, 14 Jun 2022 22:46:49 +0300
> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 14.06.2022 22:17, Eli Zaretskii wrote:
> > No, I proposed to use the "predicate function" method (which already
> > exists).
> 
> Then the downside is "it's not readable". Or editable, really.
> 
> At this point you could say that we need to support lambas anyway (ok), 
> and if people use them, we can use it for this purpose too.
> 
> But it seems to me that, by not supporting lambdas so far, over the 
> couple of years since its introduction, project-kill-buffer-conditions 
> has kind of proven its minimal DSL to be viable.
> 
> And if by having the 'major-mode eq' matcher we manage to avoid the use 
> of lambdas in 99%+ use cases, then that's a win for usability.

This is all a moot point, since eventually 'major-mode' was left in
the code.  Any of the suggestions I had for removing it are therefore
purely academic at this point, nothing to argue about.

Message #110 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 15 Jun 2022 14:48:52 +0300

On 15.06.2022 05:33, Eli Zaretskii wrote:
> This seems to be some misunderstanding.  I wanted us to have only
> 'derived-mode', not 'major-mode'.

Okay?...

> But Philip was unhappy about that,
> due to existing usage of 'major-mode', and eventually 'major-mode' was
> left in the code.  Or at least this is my recollection of the
> discussion and its resolution.

'major-mode' was left in the code and in the docs, but its meaning was 
changed. Hence the backward compatibility concern.

And 'derived-mode' was dropped.

Or you could say that 'major-mode' was dropped, and 'derived-mode' was 
left it, but renamed.

Message #113 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 15 Jun 2022 14:54:14 +0300

On 15.06.2022 05:34, Eli Zaretskii wrote:
>> Date: Tue, 14 Jun 2022 22:46:49 +0300
>> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> On 14.06.2022 22:17, Eli Zaretskii wrote:
>>> No, I proposed to use the "predicate function" method (which already
>>> exists).
>>
>> Then the downside is "it's not readable". Or editable, really.
>>
>> At this point you could say that we need to support lambas anyway (ok),
>> and if people use them, we can use it for this purpose too.
>>
>> But it seems to me that, by not supporting lambdas so far, over the
>> couple of years since its introduction, project-kill-buffer-conditions
>> has kind of proven its minimal DSL to be viable.
>>
>> And if by having the 'major-mode eq' matcher we manage to avoid the use
>> of lambdas in 99%+ use cases, then that's a win for usability.
> 
> This is all a moot point, since eventually 'major-mode' was left in
> the code.  Any of the suggestions I had for removing it are therefore
> purely academic at this point, nothing to argue about.

'major-mode' that was left works like 'derived-mode' did.

If we take your suggestion as-is, though (and rename 'major-mode' back 
to 'derived-mode'), that would at least fix the main backward 
compatibility concern.

And with that, we could go back to discussing the stuff I wrote above.

Message #116 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 15 Jun 2022 16:20:26 +0300

> Date: Wed, 15 Jun 2022 14:48:52 +0300
> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 15.06.2022 05:33, Eli Zaretskii wrote:
> > This seems to be some misunderstanding.  I wanted us to have only
> > 'derived-mode', not 'major-mode'.
> 
> Okay?...
> 
> > But Philip was unhappy about that,
> > due to existing usage of 'major-mode', and eventually 'major-mode' was
> > left in the code.  Or at least this is my recollection of the
> > discussion and its resolution.
> 
> 'major-mode' was left in the code and in the docs, but its meaning was 
> changed. Hence the backward compatibility concern.
> 
> And 'derived-mode' was dropped.
> 
> Or you could say that 'major-mode' was dropped, and 'derived-mode' was 
> left it, but renamed.

Then I'm sorry, but I don't think I have anything to do with that
change.  If I somehow cause Philip to make such changes, I apologize,
because I never meant anything even close (and cannot understand how
what I wrote could have interpreted to that effect, but that's water
under the bridge).

Once again, my only comment about the code was that I thought (and
still think) we should not use major-mode matching, but derived-mode
matching instead.

Message #119 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 15 Jun 2022 18:56:03 +0300

On 15.06.2022 16:20, Eli Zaretskii wrote:
> Then I'm sorry, but I don't think I have anything to do with that
> change.  If I somehow cause Philip to make such changes, I apologize,
> because I never meant anything even close (and cannot understand how
> what I wrote could have interpreted to that effect, but that's water
> under the bridge).

That's easy to fix, but:

> Once again, my only comment about the code was that I thought (and
> still think) we should not use major-mode matching, but derived-mode
> matching instead.

A lot of my emails in this thread are about "we should not use 
major-mode matching". That we maybe should. Because we do.

Message #122 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 15 Jun 2022 19:17:36 +0300

> Date: Wed, 15 Jun 2022 18:56:03 +0300
> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> > Once again, my only comment about the code was that I thought (and
> > still think) we should not use major-mode matching, but derived-mode
> > matching instead.
> 
> A lot of my emails in this thread are about "we should not use 
> major-mode matching". That we maybe should. Because we do.

Did you see that "was" part in what I wrote above?  I was only
describing what I meant to say back then, that's all.  Why beat that
long-dead horse 3 months after it died?

Message #125 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 15 Jun 2022 19:51:42 +0300

On 15.06.2022 19:17, Eli Zaretskii wrote:
> Did you see that "was" part in what I wrote above?  I was only
> describing what I meant to say back then, that's all.

Because your opinion made it into reality.

The main problem was caused by the divergence from your suggestion 
(apparently), but I'm also discussing more minor ones.

> Why beat that
> long-dead horse 3 months after it died?

Are you going to be fine with me changing 'buffer-match-p' to match the 
older contract of 'project-kill-buffer-conditions', with both 
'major-mode' and 'derived-mode' matchers included?

If yes, no more questions from me.

Message #128 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 15 Jun 2022 16:59:18 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Wed, 15 Jun 2022 14:48:52 +0300
>> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> 
>> On 15.06.2022 05:33, Eli Zaretskii wrote:
>> > This seems to be some misunderstanding.  I wanted us to have only
>> > 'derived-mode', not 'major-mode'.
>> 
>> Okay?...
>> 
>> > But Philip was unhappy about that,
>> > due to existing usage of 'major-mode', and eventually 'major-mode' was
>> > left in the code.  Or at least this is my recollection of the
>> > discussion and its resolution.
>> 
>> 'major-mode' was left in the code and in the docs, but its meaning was 
>> changed. Hence the backward compatibility concern.
>> 
>> And 'derived-mode' was dropped.
>> 
>> Or you could say that 'major-mode' was dropped, and 'derived-mode' was 
>> left it, but renamed.
>
> Then I'm sorry, but I don't think I have anything to do with that
> change.  If I somehow cause Philip to make such changes, I apologize,
> because I never meant anything even close (and cannot understand how
> what I wrote could have interpreted to that effect, but that's water
> under the bridge).
>
> Once again, my only comment about the code was that I thought (and
> still think) we should not use major-mode matching, but derived-mode
> matching instead.

I have to apologise myself, first of all for the mistake in the current
implementation and second of all for the late response.  I should have
clarified what I was doing, and had assumed your comments were blocking
requirements for me to push any changes.

Message #131 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 15 Jun 2022 20:29:51 +0300

> Date: Wed, 15 Jun 2022 19:51:42 +0300
> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 15.06.2022 19:17, Eli Zaretskii wrote:
> > Did you see that "was" part in what I wrote above?  I was only
> > describing what I meant to say back then, that's all.
> 
> Because your opinion made it into reality.

Sorry about that, but it was a misunderstanding of my opinion.

> Are you going to be fine with me changing 'buffer-match-p' to match the 
> older contract of 'project-kill-buffer-conditions', with both 
> 'major-mode' and 'derived-mode' matchers included?

I don't think I understand what you are suggesting.  What is that
"older contract"?  Can you show a patch?

Message #134 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Thu, 16 Jun 2022 03:47:15 +0300

On 15.06.2022 20:29, Eli Zaretskii wrote:
>> Date: Wed, 15 Jun 2022 19:51:42 +0300
>> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> On 15.06.2022 19:17, Eli Zaretskii wrote:
>>> Did you see that "was" part in what I wrote above?  I was only
>>> describing what I meant to say back then, that's all.
>>
>> Because your opinion made it into reality.
> 
> Sorry about that, but it was a misunderstanding of my opinion.
> 
>> Are you going to be fine with me changing 'buffer-match-p' to match the
>> older contract of 'project-kill-buffer-conditions', with both
>> 'major-mode' and 'derived-mode' matchers included?
> 
> I don't think I understand what you are suggesting.  What is that
> "older contract"? 

The value format that 'project-kill-buffer-conditions' supported before 
the recent change. You can look at its docstring and definition inside 
Emacs 28.1, for instance.

> Can you show a patch?

Please look at the patch attached to the very first message in this bug 
report.

https://debbugs.gnu.org/cgi/bugreport.cgi?att=1;bug=54296;msg=5;filename=0001-Generalise-buffer-matching-from-project.el.patch

The function name has changed after discussion, but the docstring is 
still relevant, and it mirrors 'project-kill-buffer-conditions'.

Message #137 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Thu, 16 Jun 2022 08:51:35 +0300

> Date: Thu, 16 Jun 2022 03:47:15 +0300
> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> > Can you show a patch?
> 
> Please look at the patch attached to the very first message in this bug 
> report.
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?att=1;bug=54296;msg=5;filename=0001-Generalise-buffer-matching-from-project.el.patch
> 
> The function name has changed after discussion, but the docstring is 
> still relevant, and it mirrors 'project-kill-buffer-conditions'.

Other things changed as well, even in the doc string, and not just in
name changes.  Going back to the original patch makes little sense to
me.  So I'd still prefer to see an actual patch, before I tell whether
I'm okay with it.

In any case, if we will keep both major-mode and derived-mode
conditions in subr.el, let's at least document that derived-mode
should be preferred where it can do the job, and major-mode used only
where derived-mode will not DTRT.

Message #140 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Fri, 17 Jun 2022 04:21:04 +0300

[Message part 1 (text/plain, inline)]

On 16.06.2022 08:51, Eli Zaretskii wrote:
>> Date: Thu, 16 Jun 2022 03:47:15 +0300
>> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>>> Can you show a patch?
>>
>> Please look at the patch attached to the very first message in this bug
>> report.
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?att=1;bug=54296;msg=5;filename=0001-Generalise-buffer-matching-from-project.el.patch
>>
>> The function name has changed after discussion, but the docstring is
>> still relevant, and it mirrors 'project-kill-buffer-conditions'.
> 
> Other things changed as well, even in the doc string, and not just in
> name changes.  Going back to the original patch makes little sense to
> me.  So I'd still prefer to see an actual patch, before I tell whether
> I'm okay with it.
> 
> In any case, if we will keep both major-mode and derived-mode
> conditions in subr.el, let's at least document that derived-mode
> should be preferred where it can do the job, and major-mode used only
> where derived-mode will not DTRT.

Sure. Here you go.

The meat of the change is intermixed here with documentation fixes (and 
the addition of support for lambdas in project-kill-buffer-conditions), 
but they should be easy enough to tell apart.

[buffer-match-p.diff (text/x-patch, attachment)]

Message #143 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Philip Kaludercic <philipk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Fri, 17 Jun 2022 04:22:21 +0300

On 15.06.2022 19:59, Philip Kaludercic wrote:
> and had assumed your comments were blocking
> requirements for me to push any changes

FWIW, I wouldn't blame you for having that impression.

Message #146 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Fri, 17 Jun 2022 08:48:48 +0300

> Date: Fri, 17 Jun 2022 04:21:04 +0300
> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> > In any case, if we will keep both major-mode and derived-mode
> > conditions in subr.el, let's at least document that derived-mode
> > should be preferred where it can do the job, and major-mode used only
> > where derived-mode will not DTRT.
> 
> Sure. Here you go.

Fine with me, with one nit:

> +Satisfied if the buffer's major mode is eq to @var{expr}.  Prefer

Using "eq" as a word in the manual is not a good idea.  We use "is
equal" elsewhere in the manual.

Thanks.

Message #149 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Fri, 17 Jun 2022 16:39:27 +0300

On 17.06.2022 08:48, Eli Zaretskii wrote:
>> Date: Fri, 17 Jun 2022 04:21:04 +0300
>> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>>> In any case, if we will keep both major-mode and derived-mode
>>> conditions in subr.el, let's at least document that derived-mode
>>> should be preferred where it can do the job, and major-mode used only
>>> where derived-mode will not DTRT.
>>
>> Sure. Here you go.
> 
> Fine with me, with one nit:
> 
>> +Satisfied if the buffer's major mode is eq to @var{expr}.  Prefer
> 
> Using "eq" as a word in the manual is not a good idea.  We use "is
> equal" elsewhere in the manual.

Thanks, done. Backward compatibility and capability are restored.

Now, if we wanted to downplay the option of doing equality comparison 
for major-mode, we could perhaps introduce a more general condition like 
'value-equal'.

That would change the definition of project-kill-buffer-conditions very 
slightly, still keeping it readable. And a gradual deprecation of the 
'major-mode' matcher could be done.

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 30f51704dc..dea11d4231 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1223,10 +1223,10 @@ project-display-buffer-other-frame
 (defcustom project-kill-buffer-conditions
   '(buffer-file-name    ; All file-visiting buffers are included.
     ;; Most of the temp buffers in the background:
-    (major-mode . fundamental-mode)
+    (value-equal major-mode . fundamental-mode)
     ;; non-text buffer such as xref, occur, vc, log, ...
     (and (derived-mode . special-mode)
-         (not (major-mode . help-mode)))
+         (not (value-equal major-mode . help-mode)))
     (derived-mode . compilation-mode)
     (derived-mode . dired-mode)
     (derived-mode . diff-mode)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.