From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#54296: Add buffer-matching functionality Date: Thu, 10 Mar 2022 10:05:04 +0000 Message-ID: <877d92unqn.fsf@posteo.net> References: <87ee3d4cli.fsf@posteo.net> <87k0d35c82.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3208"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 54296@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 10 11:06:31 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nSFgl-0000cs-2u for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Mar 2022 11:06:31 +0100 Original-Received: from localhost ([::1]:54264 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nSFgk-0000ms-19 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Mar 2022 05:06:30 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56304) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nSFgI-0000jj-Gb for bug-gnu-emacs@gnu.org; Thu, 10 Mar 2022 05:06:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39379) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nSFgI-00021B-6r for bug-gnu-emacs@gnu.org; Thu, 10 Mar 2022 05:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nSFgH-0003T1-Ub for bug-gnu-emacs@gnu.org; Thu, 10 Mar 2022 05:06:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Mar 2022 10:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54296 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 54296-submit@debbugs.gnu.org id=B54296.164690671513239 (code B ref 54296); Thu, 10 Mar 2022 10:06:01 +0000 Original-Received: (at 54296) by debbugs.gnu.org; 10 Mar 2022 10:05:15 +0000 Original-Received: from localhost ([127.0.0.1]:33276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nSFfW-0003RS-LP for submit@debbugs.gnu.org; Thu, 10 Mar 2022 05:05:15 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]:47049) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nSFfU-0003R9-A1 for 54296@debbugs.gnu.org; Thu, 10 Mar 2022 05:05:13 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 400B3240103 for <54296@debbugs.gnu.org>; Thu, 10 Mar 2022 11:05:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1646906706; bh=TZdf7yYcP+NLFQQcDOrAXRbJBteFd1YaVJ62Z9kupDE=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=hr99hmDdSg9z13wDKnodnBsnJbcjEsuXL2gsvfn6rsZwkbkDxRLGoMKcMSKjmZSqW nYFSTVfbv2PWKIVn7OBi1MVx2/32kC0kFRrSaP685WUwaASJk7Lh4WSBlDnlFTvRSm BD2EowZ0OMC2TKxHKUKSX1+tGx8iW8OY+8Dkx+geICecZQ18/duBx7vLLSuo7qmre6 QxnpzQtfxwS90Fxk/4AIzTqfYhbESVNuZ/qOPD1IGfXaUBX7bk/TldCnCVfejf9pNi gzWAjzNFPyL3KiW4C+nzGIWgYLFyzedOakOiqN7xIK0Yv1AP5GcoJSFystHowTzwdM BKM4FNHv3KDVA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4KDl6m6g7Lz6tm9; Thu, 10 Mar 2022 11:05:04 +0100 (CET) Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB In-Reply-To: <87k0d35c82.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 09 Mar 2022 17:20:45 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:228183 Archived-At: --=-=-= Content-Type: text/plain Lars Ingebrigtsen writes: > Philip Kaludercic 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: --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Generalise-buffer-matching-from-project.el.patch >From 6714a4dc7168e6806dba0707c9c0b80d3365b2c5 Mon Sep 17 00:00:00 2001 From: Philip Kaludercic 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 --=-=-= Content-Type: text/plain martin rudalics 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): --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0002-window.el-display-buffer-assq-regexp-Use-buffer-matc.patch >From fadea32d0dc74952ca70f8d98ced59616c0e3e1a Mon Sep 17 00:00:00 2001 From: Philip Kaludercic 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 --=-=-= Content-Type: text/plain > martin > -- Philip Kaludercic --=-=-=--