GNU logs - #79310, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79310: [PATCH] Filter out selected buffers in multi-occur
Resent-From: Gabriel do Nascimento Ribeiro <gabriel376@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 25 Aug 2025 16:00:02 +0000
Resent-Message-ID: <handler.79310.B.175613755325492 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 79310 <at> debbugs.gnu.org
From: Gabriel do Nascimento Ribeiro <gabriel376@HIDDEN>
Thread-Topic: [PATCH] Filter out selected buffers in multi-occur
Thread-Index: AQHcFdaaQ/MW9nrj0ECxzr6S7kTo3Q==
Date: Mon, 25 Aug 2025 15:53:51 +0000
Message-ID: <SN6PR06MB39352475AB351A7671E4440E8B3EA@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
msip_labels: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR06MB3935:EE_|PH0PR06MB7349:EE_
x-ms-office365-filtering-correlation-id: 8812d7d5-26de-4d81-fdb5-08dde3ef9675
x-ms-exchange-slblob-mailprops: znQPCv1HvwUykhYCLh9DY9coCVULpTnXPqomW5h2s5fhdOClXVTJiUSBRKmHxwLWTvf0/uI3Bsqq8nKIvAC/8Fz1PsmDiW3F9QddN505m5KHBrtAhviOuBDAB8PXKSWA4b60EP1gmncwBoFaKDNGGsy1XnELZpf8RGeL/B27gObx9mGYLAPFF0LE9lZd3cpnbQHUVjZNEpU9YywPrl1f6qtNI+5Zj8aU3cKox9zlr+l9Vvx3+5NTzpfkoPsM7pTs7yKQEro2xKfVp9HpM/4vQPj3h8Q4lnc4L266B7olM1WoPC2JQFNecJnvQSiuqodostCv0OjCENailZfCEoSGfXU/DksxKD97lE0rC+2eGO4O3wYD+PkZK7EJixhD+tPxVZFHEd0XQgDJ5BS52FH1fXeelX58gniuQc/tkssuawNloUeTv40r+BedH+x9auXqgq1qbbv5OnezwAR4Nz+RcnS9V2f22DGgdk+E/V/SHc40kkGHJzvfJtr9dFVOlrWGq19RN9qbFjEWaplgGGV0i/kXIOYIj1AdjDbJBPLTbdLdE19r5vX6+D4yk4ES3B2rXbiQQihNTycB+PrnwwY5UGeXQQpoAdnaO2H1ybObEsNL2o94KCaQN50Dg3ZmT7Js8pMkdzXpwRHBMAJuL94viPOi5H4+o4W2hkNRWSt0cUwsKTuSoYWgzBnLkQ/MYq7cCo1Sy3fopzxVHStp3pJsCErLYycuOJJrNnCwbE+wxxPFMCuhJfijCFvGgex3gNh3K6Ifvi4VPZg=
x-microsoft-antispam: BCL:0;
 ARA:14566002|8060799015|8062599012|19110799012|15030799006|31061999003|15080799012|461199028|3412199025|39105399003|40105399003|51005399003|440099028|102099032;
x-microsoft-antispam-message-info: BZprr105acYjOWGB3s7ndhH79fwZxVBqajodkhroi+Hy2ZvRkF5i3GKf6w6sflx9ORA608SnBKXBDzS1G4DZculXEFZ0ZixBnA1SCYMGk6vkQR/flcixrIrGMmsIhjClEgULmclZYLBgXb3/3ipf/pKXDyzIU0O91SfXJ5noPdUgtFYRQrH9z8ZcTpkCsymn86lcv5V4oFLC9AKiwzp+ofwXOAzd4fBur834714Fffha58Xos1LvMRhgPEBUxI7JdTVJdcvLDspY5g8J2vqmjP0wAuiBoTdybDftCwY0NOtFL3KJIL56aJqRc+MWkTBe5qEjiesqHTtfidlUXBOD56DL/Zq/BO7VJiIXAxysadimLQa+9Y8EhyrjWvUO98U7RAcrSFVlCK3t/AoYYRUtU9TzATIhFPqAJ7IjxN0cqd5itx0Q6udup/R9KclEF+291C/4KqeaBHvOuysubMDo5z70U7MDp3ALDE6iEjh8qJ3MOKMsC655cE7kiS0QO9JQe9sXn9gTk5iIdMLlygnalii2BBY3bYh6rA/X/PYRMAJOz6t2uDHJWlcJt+XJ0YhsYqs0BjmMEZDsSaNt1XnakDNtVThxrHl8ipfUPB4it3zuhST+/8jgmJamAknSBmfAbvxkiGsfzxauX/Q85UzbKIIfGaMFNGWuiJoIew4waHkCyU5vc0MYjONeWelGF655hUzCdR+6ZQEoeAXamKqnsWzB4thkgEK3vBcv4aUroM6ZhRLYxKlroJgvPNXrs5VRwEElhbDbBIekrtqQsV4IaJgAWRnvRgVwRR6b63emhFulwimNnZf1SfTzpkxkY1FdvgXBI+xQYeNY3FkfluF2x4IF9W2MUyiAZJjWCSNmDKmCX78hDxMPpwi6CLCTtMDZXOdUVjg1AVVlU18dzessvFsqbBPSIO8IpPsRimgsfiZFoA2BtLasX2nXfonBnGB3Cwve3kDS97ANO2+4hqYPJNv2hJRNRADdpd/fR4shAyN/gvVQyUQinChf7C96kwGOJxoWKpZt0Oji+L0sg3a431dxxI3idrewHncA7iCa970UYHoe1X0Od2FlrD+HB7O5Lg/zz7nP2MLxCivnbe4cGNetb6sGLbiZT2ymfoOWmWrC2dyedNrpLdhZAdOBo/RYMAgay0TmeDRG7Ju/OrWbYOlxoJYJ988FaLncsMXqrO0nrrDHbShZxuSRSUZbKt7Z/uGFLwWVwB5hE+Qut7SKRQUoaAUBgnVl9nWzBTbsdHisFDD0jOHcun+5rMcLkv8E
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: W9MvFTwXuxKTxoVIYjxJQCJs3XaY0t4nXLtLOW4Nmhx72+rHTKuLDcOaswzdHcGcRLvAASn05Pkmc/4crSGJvbkVAXGN+hUs1YwH7V0DeOb0WExgCn5gC4t2cncmQesKUAVZkAU6XKVrpyrclUCiWd6uf81Y+ED44g6hLpCUqLP99MkFY+0U3kdBt8iqkKAwfcOSZDNY2v9KG4ijWhfYV/kBoyASn0fXqnda51zeAkJJRJ8e9lamJ1Kl4jGhGsGYX3+NSDIYWKIzjoE4smN3MGqZU6tSqts3LStoEFQgSonRZXqwPwIWhd6j6/C7D0E6kgowPrMnhrogGcf1zD3X8rL3EqlqhnScw/IbOyOByZczYKU25JVqa7EUGq69wkTF5KBG4A5x1O2cSvAzKaLYOkdcH6Hqm5JUkfycVDsOXpHT1+8KHsRK8OZ0tjkvhZMH7eKxgYrH6lsJZ3UUlkosJftTrHeMwACg77bQuzT6S6lBe0HJ1nprYGc4QLVMM0EcOgw5ThlLTo6WZki6qxRJUvGXgi/WLpqKiBQO/ucapNCnNcRzSc+RIp6LQMBEPTsn3b4q/dGkM2xLnCqOxuRqADrISWwyjQgiNAqFiu3aEsmMFTASouE0LnQ1Jow60J3Mtx8P1dUpsB8I3HuImNZL/AEE8PXZhSBuuaR6bkwuoKpOzGm+fsngPEKPaYyK99DOuauilCTt4ADwUT29N0Qi0NkqyRr+MTEHa+mTb7bVznpkZDX61leqUzhlR9HtV4yhAME0vGDdSALy9rrEALxsoPeLhbjPvQlu9cvQ7kgfTGAM3nMDYS0gWneQmkyeqJBOs64QLJk8SwiBalIXF3le7eU5tM3aKLpHBxHLWh6xYqXzypj1Im/7HfMkuKNY+BUJz/yf3WGuTMlnSrdjETXyoZ/CvLFMTnw0DMzwhWABGq8jGR8IcthiHiPl5c+uL52N6df+jGZwYRy4vQ2kuEHUlNnKDe+WfWIKg2nAePAuynviv5H1sNmWoqZO2dY74d7lIFjZ+gtribGJ/TqfMN7J7eWCLZSee9DrrjqZyTH3dwlmYoL5aFU+KQ8iZ4BRxeoHMLMAptXryWZymBgqbahrIXMjFONqMIZgW1qw2xNyWANHkSTmBB+NUMWu+qyOz+gOE8zMHS4/vfKP5s7YKdCOqctfvC3er+CEjkMleIbA3c2MMrv8sHCFNESe/neWH+hJbrGWyPlk+e8uWT6xmesAHOxMrJUFufSrXuPEn7p5aRM=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-8534-20-msonline-outlook-a1430.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR06MB3935.namprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 8812d7d5-26de-4d81-fdb5-08dde3ef9675
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2025 15:53:51.7253 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7349
Received-SPF: pass client-ip=40.92.21.103; envelope-from=gabriel376@HIDDEN;
 helo=NAM12-BN8-obe.outbound.protection.outlook.com
X-Spam_score_int: -17
X-Spam_score: -1.8
X-Spam_bar: -
X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001,
 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: The proposed patch below adds a predicate function to
 read-buffer
 in multi-occur to filter out previous selected buffers. The current behavior
 does not have such filter, allowing users to select the s [...] 
 Content analysis details:   (1.2 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
 in digit (gabriel376[at]hotmail.com)
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (gabriel376[at]hotmail.com)
 0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;
 id=gabriel376%40hotmail.com; ip=2001%3A470%3A142%3A%3A17; r=debbugs.gnu.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.0 SPOOFED_FREEMAIL       No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

The proposed patch below adds a predicate function to read-buffer in multi-=
occur=0A=
to filter out previous selected buffers.  The current behavior does not hav=
e=0A=
such filter, allowing users to select the same buffer over and over, which =
can=0A=
be confusing when selecting multiple buffers, since users should keep in me=
mory=0A=
what they have already selected, and shows duplicated results in the *Occur=
*=0A=
buffer.  I don't see a reason for the current behavior, so I propose the pa=
tch=0A=
below.=0A=
=0A=
Potential improvements:=0A=
=0A=
1) When the buffer list is empty (user has selected all the buffers), it co=
uld=0A=
skip the read-buffer and go directly to next step (ask 'List lines matching=
=0A=
regexp').  Not sure how to implement it, since internal-complete-buffer doe=
s=0A=
some filtering of Vbuffer_alist to remove internal buffers, and I could not=
 find=0A=
an easy way to get the length of this filtered buffer list.=0A=
=0A=
2) I believe multi-occur--prompt is not very accurate in case an user chang=
es or=0A=
remaps related functions in minibuffer.  For instance, I use=0A=
icomplete-vertical-mode with different keybindings, but it always show '(RE=
T to=0A=
end)'.  We could make it smarter, or change the prompt to indicate that an =
empty=0A=
string terminates the buffer selection instead of trying to guess the=0A=
keybinding.=0A=
=0A=
=0A=
From e3c2932ee551db6a008f078579ae6550356647fb Mon Sep 17 00:00:00 2001=0A=
From: Gabriel Ribeiro <gabriel376@HIDDEN>=0A=
Date: Mon, 25 Aug 2025 12:38:12 -0300=0A=
Subject: [PATCH] Filter out already selected buffers in multi-occur=0A=
=0A=
* lisp/replace.el (multi-occur): Add predicate to=0A=
read-buffer to filter out previous selected buffers.=0A=
---=0A=
 lisp/replace.el | 20 +++++++++++++-------=0A=
 1 file changed, 13 insertions(+), 7 deletions(-)=0A=
=0A=
diff --git a/lisp/replace.el b/lisp/replace.el=0A=
index 8227056e012..03b274c59af 100644=0A=
--- a/lisp/replace.el=0A=
+++ b/lisp/replace.el=0A=
@@ -1853,14 +1853,20 @@ multi-occur=0A=
   (interactive=0A=
    (cons=0A=
     (let* ((bufs (list (read-buffer "First buffer to search: "=0A=
-				    (current-buffer) t)))=0A=
-	   (buf nil)=0A=
-	   (ido-ignore-item-temp-list bufs))=0A=
+                                    (current-buffer))))=0A=
+           (ido-ignore-item-temp-list bufs)=0A=
+           (buf nil))=0A=
       (while (not (string-equal=0A=
-		   (setq buf (read-buffer (multi-occur--prompt) nil t))=0A=
-		   ""))=0A=
-	(cl-pushnew buf bufs)=0A=
-	(setq ido-ignore-item-temp-list bufs))=0A=
+                   (setq buf (read-buffer=0A=
+                              (multi-occur--prompt)=0A=
+                              nil t=0A=
+                              (lambda (b)=0A=
+                                (not (member=0A=
+                                      (if (stringp b) b (car b))=0A=
+                                      ido-ignore-item-temp-list)))))=0A=
+                   ""))=0A=
+        (cl-pushnew buf bufs)=0A=
+        (setq ido-ignore-item-temp-list bufs))=0A=
       (nreverse (mapcar #'get-buffer bufs)))=0A=
     (occur-read-primary-args)))=0A=
   (occur-1 regexp nlines bufs))=0A=
-- =0A=
2.34.1=0A=
=0A=
=0A=
---=0A=
Gabriel=

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Gabriel do Nascimento Ribeiro <gabriel376@HIDDEN>
Subject: bug#79310: Acknowledgement ([PATCH] Filter out selected buffers
 in multi-occur)
Message-ID: <handler.79310.B.175613755325492.ack <at> debbugs.gnu.org>
References: <SN6PR06MB39352475AB351A7671E4440E8B3EA@HIDDEN>
X-Gnu-PR-Message: ack 79310
X-Gnu-PR-Package: emacs
X-Gnu-PR-Keywords: patch
Reply-To: 79310 <at> debbugs.gnu.org
Date: Mon, 25 Aug 2025 16:00:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 79310 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
79310: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D79310
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79310: [PATCH] Filter out selected buffers in multi-occur
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 Aug 2025 17:17:02 +0000
Resent-Message-ID: <handler.79310.B79310.175631501519772 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Gabriel do Nascimento Ribeiro <gabriel376@HIDDEN>
Cc: 79310 <at> debbugs.gnu.org
From: Juri Linkov <juri@HIDDEN>
In-Reply-To: <SN6PR06MB39352475AB351A7671E4440E8B3EA@HIDDEN>
Organization: LINKOV.NET
References: <SN6PR06MB39352475AB351A7671E4440E8B3EA@HIDDEN>
Date: Wed, 27 Aug 2025 20:14:07 +0300
Message-ID: <87wm6o8z6o.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> The proposed patch below adds a predicate function to read-buffer in multi-occur
> to filter out previous selected buffers.  The current behavior does not have
> such filter, allowing users to select the same buffer over and over, which can
> be confusing when selecting multiple buffers, since users should keep in memory
> what they have already selected, and shows duplicated results in the *Occur*
> buffer.  I don't see a reason for the current behavior, so I propose the patch
> below.

Thanks, good idea.

> Potential improvements:
>
> 1) When the buffer list is empty (user has selected all the buffers), it could
> skip the read-buffer and go directly to next step (ask 'List lines matching
> regexp').  Not sure how to implement it, since internal-complete-buffer does
> some filtering of Vbuffer_alist to remove internal buffers, and I could not find
> an easy way to get the length of this filtered buffer list.

Makes sense.  Can you do the same filtering as in internal-complete-buffer?
For example:

  (seq-filter (lambda (b) (/= (aref (buffer-name b) 0) ?\s)) (buffer-list))

> 2) I believe multi-occur--prompt is not very accurate in case an user changes or
> remaps related functions in minibuffer.  For instance, I use
> icomplete-vertical-mode with different keybindings, but it always show '(RET to
> end)'.  We could make it smarter, or change the prompt to indicate that an empty
> string terminates the buffer selection instead of trying to guess the
> keybinding.

Changing the default text to not mention RET would be nice.

> @@ -1853,14 +1853,20 @@ multi-occur
>    (interactive
>     (cons
>      (let* ((bufs (list (read-buffer "First buffer to search: "
> -				    (current-buffer) t)))
> +                                    (current-buffer))))

I wonder why you removed t from the REQUIRE-MATCH arg of read-buffer?
This allows the user to enter an non-existent buffer name.

>        (while (not (string-equal
> -		   (setq buf (read-buffer (multi-occur--prompt) nil t))
> -		   ""))
> -	(cl-pushnew buf bufs)
> -	(setq ido-ignore-item-temp-list bufs))
> +                   (setq buf (read-buffer
> +                              (multi-occur--prompt)
> +                              nil t
> +                              (lambda (b)
> +                                (not (member
> +                                      (if (stringp b) b (car b))
> +                                      ido-ignore-item-temp-list)))))

Wouldn't it be more clear here to use 'bufs' instead of 'ido-ignore-item-temp-list'?

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79310: [PATCH] Filter out selected buffers in multi-occur
Resent-From: Gabriel do Nascimento Ribeiro <gabriel376@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 Aug 2025 18:15:02 +0000
Resent-Message-ID: <handler.79310.B79310.17563184963760 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Juri Linkov <juri@HIDDEN>
Cc: "79310 <at> debbugs.gnu.org" <79310 <at> debbugs.gnu.org>
From: Gabriel do Nascimento Ribeiro <gabriel376@HIDDEN>
Thread-Topic: bug#79310: [PATCH] Filter out selected buffers in multi-occur
Thread-Index: AQHcFdaaQ/MW9nrj0ECxzr6S7kTo3bR2wFCAgAAOunw=
Date: Wed, 27 Aug 2025 18:14:41 +0000
Message-ID: <SN6PR06MB3935D4E1ED27B0EE271354198B38A@HIDDEN>
References: <SN6PR06MB39352475AB351A7671E4440E8B3EA@HIDDEN>
 <87wm6o8z6o.fsf@HIDDEN>
In-Reply-To: <87wm6o8z6o.fsf@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
msip_labels: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN6PR06MB3935:EE_|SJ0PR06MB8925:EE_
x-ms-office365-filtering-correlation-id: 77997012-1c64-4a29-2d08-08dde595979a
x-ms-exchange-slblob-mailprops: YfhX3sd/0TVWrg+fxRScxfg9v9HXnUFl4FHPVqGsxtPhORvuo7xGU83t74DdkNJquJFHcahIyMrqEpIoTReAf9lXVkhL/nS+xVnHcC042Enx1kPHBkUvZVq5MzEObtXulZjE0yJDeg9sqw05ZedwI+rWov7ajVPkbDbQiQEUq+lr2030pRK6frnwr4tA379YoRsJR8GBVmM7uyRIMsjrmgaZ1i6s4BJiG1rZvgxbLx2s6gDzNv6e2gm7lh+fZX0Sk5jzzgQNVMob7EHZ6u4FWL6wtioIKDQT+GABkjuFxgXjUANgniUJytY8l9dICTjDi0thoqoxoqi4KIq3r3ezDX8HUMwkkxafVkoJXOEnme0UD25xu+THleOgACiauJ/zX6138R992Z57Zk8PaWUkWUQPH2jRfnUMbx+Qt/BfLHcyoKV/hr1UoUDQeyPMo4Pi/L6PBohFoQDZZ9694c8TDURogxkdWuQo1sUxUX9XN5WvpZjvo4xel7hl6ifXwXq34jeXMhiC7MqkbxdcpxsMXEHfo7KjnyUEGwEOgyYBHXpSGUyPDdlWLxVUj9u+ObwjApPx7hJE7LElBz0nFLH1NMRWLUOB5qaAYDY+GeLCkF3DK8u9vsxbWVmhZO9vwxiXKWg8B3z7qG8AEx4xEdq6AhpeVlELOVhj1wlk+pKmWpunF2rQZZfUARxI5xWcVcLRQYiN16GWGAPYhn2RE+fgtuOWIw+9W5+/aLoEdERJ+7nz/QjgZ77+ISgqxrXurRVtMBlEEvnIUJKDbMaIP6cQyGG7U8b90R8UA38Z0r/HRCo=
x-microsoft-antispam: BCL:0;
 ARA:14566002|31061999003|15030799006|461199028|8060799015|8062599012|15080799012|19110799012|102099032|52005399003|40105399003|3412199025|440099028;
x-microsoft-antispam-message-info: r7qVyTK6TeoXdqrR0NvIXwZJMVv5a9hbN/Nf+JAbfCIU5LRTiHERnLWhDtAwIm+SREqbo2PwKe0mZ9y0w2cV+UjcUvJIv6mVaYsppX5wzGCrxD02exDNKFqOzLMCDpe0+YyDEE8mC/XKIMjRJSe5oHYcYNH4hsqklMOqH1TYxrWiJK3nGZCluqyVFduclZNbxWqxv3K5JzwkOd+QlAbl22yQqDyMQ9KeGPVK0k+pPid/cPs9mGihjHxhlv9MjYpD1dDrUpApRlyyo0g4mO/MMMH75S7TYt1GF5Hx1HfqMNF+uxD/kxaa7UD9yBvJy6p1HQ6qIFLvFpV4lRAAD6IvSicwXG2LuqOCD7mwJpT3lRGEgIgO94B5nrXg/QXDRUZU6a9gmq3nC+3aQ3eM81owX3IWdHvxPPPHEnxW7Xc2W1xNHlm5fp6NePneUfycfTMMGJTzMAj2LxqpCNY9X/x9iFYw7bGil6HSLmM34m343ScoNI3KPMJ1quSdpwbe1i4BHYufl3+IHn6gAsNbZvL19ka/MrZTPTs0egZHrgqkIYdRNURmZXlogk3x3hirNVamXygm//VBGLlxvsr5DlGr8o1q8mUfmjuLZBwGlk0jvYVwHBsO7U7A6K47vpzYGM6kVblicUVAbZ7le+hn7xZd3rty2slNTpdFktxvRSkOStWNERRbljOlEAbpZl/0P799B8UwNNm4zRmWBeu4iUT7B2m8kMnRST3R/iq5+DahnPAeUTIZbcx7XgCeQRgbwj3eShBiGmZ6u/JXHmZn4iwMZQatmulmqEQ1H3Y/EZYMO3v+d/oNoxN27p2BEFZOhKwVQaX9b0XJM9A5lSXhv6rTAm7DBSHTvYbmIGXaGXOkpB6iKMLhDwv3zVlUDkSl5JejYov31mTKfvABFxbtxiVmCYGKLP8GBceQF/Aa99LD78+Gz1fx/Yn4lxTqXnTtjf/Vl12oEISgs7ZfbLfti9x00vHUHAARip4gZsK4jiI9UGSUmYdjVxTspM/FeN9wrPpM/HX42LrSk/2g0vJdYX77ccOuKoWPe4TBTZqTuu1NhGIsq+eXUwISCq6mOIhrbcqTeeFoiT3ehz6cYBG6Oky2XwE+X54QpT2juDrqRG5/luUjMKiHvH8LSIR6EMxSr5U6wb2mhZYmNTL6ccUtvjbbWNRIKj7O37SvfbzEwXk4pjFT9xZ9/wVlwG+Rb48u2F2gUrtusUa+yL8wwn4cdL2coQ==
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: X+0wQM7SW4p7r1NdiGA5DRkroJSSg+zxrtbrlDLpMWM4VP2KUF1GyMWyYc6RrlfkYUpYU1qcGcB4CoDMaoaTAqUvQ0xQC0Zo/9jO2/BzGtGrfYnYtlDy1nhVVKnHnsQWujRmNrN/jaMp7IhOWovUJ9sVkJr6pUnj+bldkjnoM/nr12Z1XemCI4Fal1L5/EYYZFKy2sqPJwBy7302pRxc6DtTW3CGWkKtV8S4mAewDZagelqalOtcO/ArTWbrNfCtCJL/c5qRQY2mPLdjIsbRJk5dBsXvpTNqHftWninlPCuO2wm9Zhqh5wZai2C4ihWw/oLy7EySEvHVFltfXnZeCnO4DKb5zYS4n5118e90befbEGztMw/Z+TLnN/lAwu3+Ek3tSEFzlgrPJBZDLu0RzOGhoxxb9J7ZHyT2/WD59L1J6KQXo7scFWblXdSAIHjLag52jbH1a0IpAMMUthAZ+F+MeCNoJ7x3vEYDDEK7Vq1533orEEZZefYW+QOt/G3ycie5lzA5/yc26YCn2LxtAGuCjBm1ZXdvh6cdIjetnO7vRvC8/r9xeD/+2E7AYiUUHjl9Hl24hVQMuRr4ghmz+Qut8bpwFTfAr/DByxMPPke20cDLfseUjGLW9DLlb5IcG4Lf3IWR+KEPLEss0XMfBvROflUrsyBCe86+gOMq0B3cG5H22X856MVhcd9RWV0C6PsDe8J/g2NreUyY5qiZzAjkbms9Nwi73Q3otykC1FU4CtvfREVCWoNqXaR8ZYysiUKZS2DS4bYx3FxobYvVDeTA2JYLB+FFrEpdQqCN6kUsvjWU/7y/4ewZtT7OgH9yO4NIt2jvGSuC7GER/dmEZF5UPVTNpd5/6s79Qgzsjsdbt4yDF7N+uyAdcYnKwIASEiP1sLmAMT+zteisNg7PO6/DujcQ79h6du6RSoww5P05Qy7f0fIXyJffuW5G0O4hcruok+eJ5T9XVAuDzbSXp3m+gKAe22bvo7cSOXNfJudvIVPrVgtnkokbXFQIZgu5D18ZscFeajtLGy8bJiGjXs87KUoFKkXN953tco7idAE605Eelxtg40uxxItoO/YbG35bYET5va+uyWNLWdV8ve28vhsyNHc3/E8Lt0mXdR+pImdBHL7FJeAg5v4QLHwT7qyVPQi6/3gl3S41W615wRMJ6jOL7zuEbvsR9eCspJhepatNn1LAFsZC6js20eYHzloZwd73Wz4xjlCkxPWL2tNdAwZ0yDkQbGh40ISaybo=
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-8534-20-msonline-outlook-a1430.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR06MB3935.namprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 77997012-1c64-4a29-2d08-08dde595979a
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2025 18:14:41.2239 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR06MB8925
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

> Makes sense.  Can you do the same filtering as in internal-complete-buffe=
r?
> For example:
>
> (seq-filter (lambda (b) (/=3D (aref (buffer-name b) 0) ?\s)) (buffer-list=
))

I'll give that a try, thanks for the suggestion.
Of course, if someone wants to install a different patch, that=92s fine too=
; mine was
just meant as a starting point for discussion.

> I wonder why you removed t from the REQUIRE-MATCH arg of read-buffer?
> This allows the user to enter an non-existent buffer name.

That was a mistake on my part, thanks for catching it.  It should definitel=
y remain t.

> Wouldn't it be more clear here to use 'bufs' instead of 'ido-ignore-item-=
temp-list'?

From what I saw, ido-ignore-item-temp-list (declared in ido.el) seems relat=
ed to an
older implementation for ido-mode, but I didn=92t look into it in detail.

---
Gabriel

________________________________________
From: Juri Linkov <juri@HIDDEN>
Sent: Wednesday, August 27, 2025 2:14 PM
To: Gabriel do Nascimento Ribeiro
Cc: 79310 <at> debbugs.gnu.org
Subject: Re: bug#79310: [PATCH] Filter out selected buffers in multi-occur

> The proposed patch below adds a predicate function to read-buffer in mult=
i-occur
> to filter out previous selected buffers.  The current behavior does not h=
ave
> such filter, allowing users to select the same buffer over and over, whic=
h can
> be confusing when selecting multiple buffers, since users should keep in =
memory
> what they have already selected, and shows duplicated results in the *Occ=
ur*
> buffer.  I don't see a reason for the current behavior, so I propose the =
patch
> below.

Thanks, good idea.

> Potential improvements:
>
> 1) When the buffer list is empty (user has selected all the buffers), it =
could
> skip the read-buffer and go directly to next step (ask 'List lines matchi=
ng
> regexp').  Not sure how to implement it, since internal-complete-buffer d=
oes
> some filtering of Vbuffer_alist to remove internal buffers, and I could n=
ot find
> an easy way to get the length of this filtered buffer list.

Makes sense.  Can you do the same filtering as in internal-complete-buffer?
For example:

  (seq-filter (lambda (b) (/=3D (aref (buffer-name b) 0) ?\s)) (buffer-list=
))

> 2) I believe multi-occur--prompt is not very accurate in case an user cha=
nges or
> remaps related functions in minibuffer.  For instance, I use
> icomplete-vertical-mode with different keybindings, but it always show '(=
RET to
> end)'.  We could make it smarter, or change the prompt to indicate that a=
n empty
> string terminates the buffer selection instead of trying to guess the
> keybinding.

Changing the default text to not mention RET would be nice.

> @@ -1853,14 +1853,20 @@ multi-occur
>    (interactive
>     (cons
>      (let* ((bufs (list (read-buffer "First buffer to search: "
> -                                 (current-buffer) t)))
> +                                    (current-buffer))))

I wonder why you removed t from the REQUIRE-MATCH arg of read-buffer?
This allows the user to enter an non-existent buffer name.

>        (while (not (string-equal
> -                (setq buf (read-buffer (multi-occur--prompt) nil t))
> -                ""))
> -     (cl-pushnew buf bufs)
> -     (setq ido-ignore-item-temp-list bufs))
> +                   (setq buf (read-buffer
> +                              (multi-occur--prompt)
> +                              nil t
> +                              (lambda (b)
> +                                (not (member
> +                                      (if (stringp b) b (car b))
> +                                      ido-ignore-item-temp-list)))))

Wouldn't it be more clear here to use 'bufs' instead of 'ido-ignore-item-te=
mp-list'?

Last modified: Wed, 27 Aug 2025 18:30:02 UTC

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