From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Jul 2024 18:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 72019@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.17205498889903 (code B ref -1); Tue, 09 Jul 2024 18:32:01 +0000 Received: (at submit) by debbugs.gnu.org; 9 Jul 2024 18:31:28 +0000 Received: from localhost ([127.0.0.1]:54054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRFcd-0002Zf-J7 for submit@debbugs.gnu.org; Tue, 09 Jul 2024 14:31:28 -0400 Received: from lists.gnu.org ([209.51.188.17]:47792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRFcb-0002ZX-EQ for submit@debbugs.gnu.org; Tue, 09 Jul 2024 14:31:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRFcU-0003EF-7b for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 14:31:18 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRFcS-0006YE-Ev for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 14:31:17 -0400 From: Spencer Baugh Date: Tue, 09 Jul 2024 14:31:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1720549871; bh=sEpLYNVU6XtDRC99KdGm6vKpGtP0L0wnVakZ/3pphu8=; h=From:To:Subject:Date; b=AYBp5hIZzhgqbK9MTVOCeO6242k94bGjvlJpe1gz2GRRQleAy4m23Xwbk2Sw1yqCJ vDEAlwGdxDijlmkzsbYBtwrTxEfLJFg4aoxWXOH6SKiBJOOCSIbl83rnSRW0sCnRRb JlQ3DjGL/8VlOba/ErSpDsK2aA0gk9CS9tc9pE0QbmT8okA3BunXXsAAmjJJyvQtHx bVqeCvyvypq3iwNlGh+CioDW/G57UT9N+Osdo6vULSR3u2amc5M+6Rc5H1AQ5vpttr fCeAjvxHkow9jDyRrJ0rNEkBdUCGyiYHJqSXr/MUcQUAooiTg77rTO2mtmVCXDmgQP 36ki+Uk80HLyA== Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) --=-=-= Content-Type: text/plain Tags: patch Previously, project-kill-buffers always called (project-current t). A Lisp program could change what project project-kill-buffers operated on by binding project-current-directory-override. However, in some edge cases (for example, if the project was deleted between looking it up and calling project-kill-buffers) this might fail to detect a project, and so (project-current t) would prompt the user. To avoid this, accept the project to kill buffers for as an argument. * lisp/progmodes/project.el (project-kill-buffers): Take project as an optional argument. In GNU Emacs 29.2.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2024-06-01 built on igm-qws-u22796a Repository revision: fcef787a846f0c51f7443dfab6af6e18b476b166 Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.10 (Green Obsidian) Configured using: 'configure --with-x-toolkit=lucid --without-gpm --without-gconf --without-selinux --without-imagemagick --with-modules --with-gif=no --with-cairo --with-rsvg --without-compress-install --with-native-compilation=aot --with-tree-sitter PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-Add-project-argument-to-project-kill-buffers.patch >From 5fdd9735148a5b009c0a2a4339c88bf8ab177f37 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Tue, 9 Jul 2024 14:30:27 -0400 Subject: [PATCH] Add project argument to project-kill-buffers Previously, project-kill-buffers always called (project-current t). A Lisp program could change what project project-kill-buffers operated on by binding project-current-directory-override. However, in some edge cases (for example, if the project was deleted between looking it up and calling project-kill-buffers) this might fail to detect a project, and so (project-current t) would prompt the user. To avoid this, accept the project to kill buffers for as an argument. * lisp/progmodes/project.el (project-kill-buffers): Take project as an optional argument. --- lisp/progmodes/project.el | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index b7c1698f50b..3d0f742c51d 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1715,7 +1715,7 @@ project--buffers-to-kill bufs)) ;;;###autoload -(defun project-kill-buffers (&optional no-confirm) +(defun project-kill-buffers (&optional no-confirm project) "Kill the buffers belonging to the current project. Two buffers belong to the same project if their project instances, as reported by `project-current' in each buffer, are @@ -1725,9 +1725,11 @@ project-kill-buffers NO-CONFIRM is always nil when the command is invoked interactively. +If PROJECT is non-nil, kill buffers for that project instead. + Also see the `project-kill-buffers-display-buffer-list' variable." (interactive) - (let* ((pr (project-current t)) + (let* ((pr (or project (project-current t))) (bufs (project--buffers-to-kill pr)) (query-user (lambda () (yes-or-no-p -- 2.39.3 --=-=-=-- From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Jul 2024 20:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh , 72019@debbugs.gnu.org, Eli Zaretskii Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172055520518997 (code B ref 72019); Tue, 09 Jul 2024 20:01:02 +0000 Received: (at 72019) by debbugs.gnu.org; 9 Jul 2024 20:00:05 +0000 Received: from localhost ([127.0.0.1]:54177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRH0O-0004wK-OR for submit@debbugs.gnu.org; Tue, 09 Jul 2024 16:00:05 -0400 Received: from fout4-smtp.messagingengine.com ([103.168.172.147]:55651) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRH0M-0004vG-Fj for 72019@debbugs.gnu.org; Tue, 09 Jul 2024 16:00:02 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id 8FC631380B02; Tue, 9 Jul 2024 15:59:51 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 09 Jul 2024 15:59:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1720555191; x=1720641591; bh=UvEJytwK8QFfdiau1tiXLuByoTE/rFZnW+xTf8X9A3k=; b= SgjbkhkC9g7nCG3wpBY0NxOxs6Pd2dJ6qvb1VZx5cE1YxJRAw/o5+UDbdYstuaBD QTSB085dna8uqNyd/X573Zd66QXbbui82Uy70dAtzdq9CYk0Ue7FZ3tYFTSzQ2i5 gpUI3OIBd5I3ytnNKyrlnF9LuaqF8XvVs40YlxgVIWqXjf8X6uTjUTSn/OnkgAQu /Qk9AvXveCjaEuwnzHlzI32gPCyAQqTAl+0Kr/M4AoVrYA7ACMgZfS/zzOloEiz2 7Ndk/L1FKjDj0/5nBwcfgeN4kmQD4DH8z3vIgAcFViL0kW3qW0yu4lK/EwCc6i7c OOUodJ69ZO3k8UvOswNu8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1720555191; x= 1720641591; bh=UvEJytwK8QFfdiau1tiXLuByoTE/rFZnW+xTf8X9A3k=; b=s 1debmapFvPoixnd7Ie5c2aEGwQeXd1515J4QKmk3NBsJCDSD259mN1u7p5P09pTm PG7n0DDz+sCWOq+uHVGRjZH1csOPhvpzbEr7N0bhbvZKeUjoeLnd4Dp4tEBR0HI6 P2Sy4RJxOeL+mKBCxxBmcfrFPw7C5Usf0UKgT5zAbKVja8rWuuGVWM4AnnZGcG08 TUjXuSDjUSKqFRe1KKRkk71YrBZpVWG+c9NuDmDjunJvjutzDOCce5CTc5onqPhG G3axMs6A/XXoxgRAYV7BNnzSF/N0KpgjQEQZl/Jt0fVKV0nwtPwju/sZL4YO3d2u osu2hn4GKxsHZFqQueq1Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdelgddugeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpedthfeuvddtveelgeeuleevvdejveehffevveehvdeuffdtfefhvdeugefgtefg tdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 9 Jul 2024 15:59:49 -0400 (EDT) Message-ID: <8e654f47-04bd-4089-92c4-dfb49132397c@gutov.dev> Date: Tue, 9 Jul 2024 22:59:46 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hi! On 09/07/2024 21:31, Spencer Baugh wrote: > Tags: patch > > > Previously, project-kill-buffers always called (project-current t). A > Lisp program could change what project project-kill-buffers operated > on by binding project-current-directory-override. However, in some > edge cases (for example, if the project was deleted between looking it > up and calling project-kill-buffers) this might fail to detect a > project, and so (project-current t) would prompt the user. > > To avoid this, accept the project to kill buffers for as an argument. > > * lisp/progmodes/project.el (project-kill-buffers): Take project as an > optional argument. LGTM. Eli, is this okay for emacs-30? From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2024 11:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172061039116619 (code B ref 72019); Wed, 10 Jul 2024 11:20:02 +0000 Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 11:19:51 +0000 Received: from localhost ([127.0.0.1]:54993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRVMU-0004Jy-Tl for submit@debbugs.gnu.org; Wed, 10 Jul 2024 07:19:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42518) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRVMS-0004Jj-IZ for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 07:19:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRVMG-0004nY-DI; Wed, 10 Jul 2024 07:19:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=IhQdW3G68M8GKMm4kcVkKwg9girBwPUxMMh9bcIXQHk=; b=WKpghYqmImOs VyKCkWTiF8AJ5Ue7kIP/D6qrnrV9wZz3gsvs8kWa9hruBwhRK0eaSw4I7yAFazYzHLuQdRn2gSKbU t3iTf1R5Qkm6sn+ppkQRTXmFkI9NJqMSAVLGGgiQpXg9+lMc14k5WPaVVCupyHaWeuWlOF9OsrZfe xTEHa7KiIu/D+u0peVPO9dOmduwkmWT+71wFssMpmQHme9TNrakCoTffxxvmkpT2r1+JK4qw/N8Tu 0vn/f5Rw/HeKiE5IVEAkqZbzx8pP9fwN/D5itqDFuCd/m00j6dxmcgwVTXTl2EYM/7V7DL9eLH1++ wtWHFwnZ/TiSeYrH17otEg==; Date: Wed, 10 Jul 2024 14:19:31 +0300 Message-Id: <86ed81o5oc.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Tue, 09 Jul 2024 14:31:11 -0400) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Tue, 09 Jul 2024 14:31:11 -0400 > > Previously, project-kill-buffers always called (project-current t). A > Lisp program could change what project project-kill-buffers operated > on by binding project-current-directory-override. However, in some > edge cases (for example, if the project was deleted between looking it > up and calling project-kill-buffers) this might fail to detect a > project, and so (project-current t) would prompt the user. > > To avoid this, accept the project to kill buffers for as an argument. That sounds like sweeping some minor bug under the carpet, or worse. Why is it a good idea to silently second-guess what is TRT in these marginal cases? Up front, I'd say asking the user is a safer bet. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2024 11:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172061183229887 (code B ref 72019); Wed, 10 Jul 2024 11:44:02 +0000 Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 11:43:52 +0000 Received: from localhost ([127.0.0.1]:55035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRVjk-0007lz-BU for submit@debbugs.gnu.org; Wed, 10 Jul 2024 07:43:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRVji-0007ll-9E for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 07:43:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRVjV-0000yz-Tx; Wed, 10 Jul 2024 07:43:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=atrF94FztqgR094xeHGPslItGb2zDj3hZ89M/GN1HeQ=; b=MofHPK5wkCRO 2RoFxlIsHkyAijI06mVQGGCDCZtCbQO8v7UnMKH9Rwrciwg0vsyJJkLMeCgobcArlAGuU//PtXWj5 CqDFZAgn2bSBcXktQfsWGm477T2CXo8RFq22Zkejawy295tW2ReyZLe+2YQm5018aJr2ogbbC/egH H9amlY4hCkPFb+eQq3iZ5sYub/npc1Dcse38dJo8pUiXyeGapIiKIlLTfBPi+W2hDTjDO/7quqd31 wiqoLV26x/sqh54gU0P0SBNriYo2W34NyDP9KhG3dv5kLH1WP0cw07QWTlx4BR3BWnbRQ9FhFC8TI u1wUW5bsZZGcLt28LYHqeQ==; Date: Wed, 10 Jul 2024 14:43:19 +0300 Message-Id: <86a5ipo4ko.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8e654f47-04bd-4089-92c4-dfb49132397c@gutov.dev> (message from Dmitry Gutov on Tue, 9 Jul 2024 22:59:46 +0300) References: <8e654f47-04bd-4089-92c4-dfb49132397c@gutov.dev> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 9 Jul 2024 22:59:46 +0300 > From: Dmitry Gutov > > Hi! > > On 09/07/2024 21:31, Spencer Baugh wrote: > > Tags: patch > > > > > > Previously, project-kill-buffers always called (project-current t). A > > Lisp program could change what project project-kill-buffers operated > > on by binding project-current-directory-override. However, in some > > edge cases (for example, if the project was deleted between looking it > > up and calling project-kill-buffers) this might fail to detect a > > project, and so (project-current t) would prompt the user. > > > > To avoid this, accept the project to kill buffers for as an argument. > > > > * lisp/progmodes/project.el (project-kill-buffers): Take project as an > > optional argument. > > LGTM. > > Eli, is this okay for emacs-30? As I wrote a few minutes ago, I don't think I like this change in principle, let alone for Emacs 30. Feel free to point out where I'm wrong or what am I missing. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2024 13:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.17206180528531 (code B ref 72019); Wed, 10 Jul 2024 13:28:02 +0000 Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 13:27:32 +0000 Received: from localhost ([127.0.0.1]:55144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRXM4-0002DW-0G for submit@debbugs.gnu.org; Wed, 10 Jul 2024 09:27:32 -0400 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:50045) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRXM0-0002DA-O6 for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 09:27:29 -0400 Received: from mail-lf1-f72.google.com ([209.85.167.72]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.97.1) id 1sRXLp-00000009AvJ-0yTv for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 09:27:17 -0400 Received: by mail-lf1-f72.google.com with SMTP id 2adb3069b0e04-52ebdb0ef28so1698958e87.0 for <72019@debbugs.gnu.org>; Wed, 10 Jul 2024 06:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1720618036; x=1721222836; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8egLtGg5dmF4VuYJutIPIzfQ69V3eFTR6nrrSr0hyNE=; b=wmYNvKm7rBWqnWSvbD9pfG7Vxhk9p8d/sI3Y/U3/ypMS9uQXmcl0ETDV49lNuIHCoW gIbrSp9YguOXvLJZRVYTqyIbUO6O6bU49y79prJ7Cbwsive8D6eUf3jjS2g9Rj2oTy4k JQX+EVYVmat8HxxG4bZk4CkdaOZQ87XmBHrFg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1720618037; bh=8egLtGg5dmF4VuYJutIPIzfQ69V3eFTR6nrrSr0hyNE=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=tmcErx0j/hVdscsRE++8QfhzGIMV+dwJI+/RMQk/xTDifmkVrHly2xt0s3US0Rv4d hj+euP1tdm8Sr1JcW+jpvPMWH5D+t7qU/NZK+gvI6Bgffwk/6cMXhltySgHhhpS/dO 0P7/NjPxY0wpF/TFDpaPnU4cpMcQHRrkAlHgQv2CcbbtGDc/1fPOCq2avFfNIUVuNl 5KCIZciNtHJBD6z2ASkY7ggdkHE0Mq7PlGtIsNJeSyZc326LCS+teC4ei5qSlX6FEI LgtPL6gUgztJSGN9tnbaZa8bwMXxJUyy6UYD2xWZOJqG4DXqBiwB08+C+mBLZ9UEPM gRDbBZ2d4PxPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720618036; x=1721222836; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8egLtGg5dmF4VuYJutIPIzfQ69V3eFTR6nrrSr0hyNE=; b=JXsfGFq+9AWze9ykK4cTB9H6e4eCyQPKDZx7dAOLiwFQHtxxCVjK9gH5xkq5ZkFR3K bm6lywS5AQO0N5qAKKvJC7ma5iic6vxYvhTgDYqjLdZhgiVWHTj+dqQoFLS213G0Jqjt IAVaF3wOBJgoMBUCskq/QCN7CyyuUi0VMrMXDLBdSqxC9Wvc/u9HluevY15HGsg5BaZ8 QT2SFl3JFOZi7nTzM3GZeweNpgCrUS25bUsIIWMw8vHGuuZOaMehKU+zy4eXoL8fukD/ Hf9Z/8thce6PCmYu4mb+cBrT565Iu5DwSpIFFnJwP3FKvCnzAMMfB2TJVNx1kfJgCCBa QwCQ== X-Gm-Message-State: AOJu0YzVcXpbdUWN8CMfB5BBZSgJWeJ74X3DNrFt2XNOxpEFDKNtyyNN p0NFWHkJbIwnU35KA+7j3eIof/iGhp5CnYzoqHK7579fa87NUPyEFuDNRoqR9kg2kpTgnGNO2Oj fb8vHs7cNM4Mb5yloA6pb8AXVNXJARZcIImePezA42cxeheQN/bPLpXoqlbTBTgKAkYq7t4P3Wu U+tm5OCDZEwhRSHcn3azLjl3C3wQ== X-Received: by 2002:a05:6512:3f14:b0:52c:df55:e11a with SMTP id 2adb3069b0e04-52eb9990a43mr4400466e87.9.1720618036252; Wed, 10 Jul 2024 06:27:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFNqFZ5726eqdgQRpEXewxgydyNXGzxwr45k0GlNUYn0l3T8ncyV2Pu97AEypIFq+WVRV2+u8KU8bPyULgNlHI= X-Received: by 2002:a05:6512:3f14:b0:52c:df55:e11a with SMTP id 2adb3069b0e04-52eb9990a43mr4400452e87.9.1720618035786; Wed, 10 Jul 2024 06:27:15 -0700 (PDT) MIME-Version: 1.0 References: <86ed81o5oc.fsf@gnu.org> In-Reply-To: <86ed81o5oc.fsf@gnu.org> From: Spencer Baugh Date: Wed, 10 Jul 2024 09:27:06 -0400 Message-ID: Content-Type: multipart/alternative; boundary="000000000000d1532b061ce49a2c" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000d1532b061ce49a2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2024, 7:19=E2=80=AFAM Eli Zaretskii wrote: > > From: Spencer Baugh > > Date: Tue, 09 Jul 2024 14:31:11 -0400 > > > > Previously, project-kill-buffers always called (project-current t). A > > Lisp program could change what project project-kill-buffers operated > > on by binding project-current-directory-override. However, in some > > edge cases (for example, if the project was deleted between looking it > > up and calling project-kill-buffers) this might fail to detect a > > project, and so (project-current t) would prompt the user. > > > > To avoid this, accept the project to kill buffers for as an argument. > > That sounds like sweeping some minor bug under the carpet, or worse. > Why is it a good idea to silently second-guess what is TRT in these > marginal cases? Up front, I'd say asking the user is a safer bet. > Suppose if some Lisp program runs (project-current t) to select a project to operate on, then does some things, then runs project-kill-buffers. The p-k-b call should never prompt for a project again - it's intended to operate on the project that was already selected. If the project that was already selected has disappeared, an error is better than a confusing second prompt which might lead to the user selecting another different project and killing all the buffers in that project. If the Lisp program wants to catch that error, it can. > --000000000000d1532b061ce49a2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 10, 2024, 7:19=E2=80=AFAM Eli Zaretskii &l= t;eliz@gnu.org> wrote:
> From: Spencer Baugh <sbaugh@janestree= t.com>
> Date: Tue, 09 Jul 2024 14:31:11 -0400
>
> Previously, project-kill-buffers always called (project-current t).=C2= =A0 A
> Lisp program could change what project project-kill-buffers operated > on by binding project-current-directory-override.=C2=A0 However, in so= me
> edge cases (for example, if the project was deleted between looking it=
> up and calling project-kill-buffers) this might fail to detect a
> project, and so (project-current t) would prompt the user.
>
> To avoid this, accept the project to kill buffers for as an argument.<= br>
That sounds like sweeping some minor bug under the carpet, or worse.
Why is it a good idea to silently second-guess what is TRT in these
marginal cases?=C2=A0 Up front, I'd say asking the user is a safer bet.=

= Suppose if some Lisp program runs (project-current t) to select a project t= o operate on, then does some things, then runs project-kill-buffers.=C2=A0 = The p-k-b call should never prompt for a project again - it's intended = to operate on the project that was already selected.=C2=A0 If the project t= hat was already selected has disappeared, an error is better than a confusi= ng second prompt which might lead to the user selecting another different p= roject and killing all the buffers in that project.=C2=A0 If the Lisp progr= am wants to catch that error, it can.
--000000000000d1532b061ce49a2c-- From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2024 14:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172062203917292 (code B ref 72019); Wed, 10 Jul 2024 14:34:01 +0000 Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 14:33:59 +0000 Received: from localhost ([127.0.0.1]:56888 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRYOM-0004Up-Fr for submit@debbugs.gnu.org; Wed, 10 Jul 2024 10:33:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57644) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRYO6-0004UG-4w for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 10:33:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRYNu-0007Fw-8a; Wed, 10 Jul 2024 10:33:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=mihEuHutWlJMrh0ChnV7MljSC718MF81Jm6Fd0U8p3Y=; b=qPf1aZNERHpk77/E7jGY CyHZXwzHUHyV3b4WXzYdrNd0QQxTPzQ6EEKelFggImhkXMyM7NWjwBnFC6RWhcNpvyNbuDzbaVuiq fko795bzSI20seGwxIxZQH8zZKaVbQfJmbTbKzp2nFK4h8lZtHsSMYgo1hRfLCkVOhgMCXVRPHC7c OmMfUhFbYFMVTQGuv8XIWH7Z2COxENLHXU3yDoJ9XjLu+txZMBERKjVcLuoOO59zEjhBEpohpDZfa QjClW3BsTP1LUDu0j4+NvaR+s6s1AV1igtlQaSdSgD7wWtNfZgYhP+PHMpvEYTTGjvk7nfl0/TnR4 n4zup8akBthsrA==; Date: Wed, 10 Jul 2024 17:32:56 +0300 Message-Id: <8634ohnwpz.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 10 Jul 2024 09:27:06 -0400) References: <86ed81o5oc.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Wed, 10 Jul 2024 09:27:06 -0400 > Cc: 72019@debbugs.gnu.org > > On Wed, Jul 10, 2024, 7:19 AM Eli Zaretskii wrote: > > > From: Spencer Baugh > > Date: Tue, 09 Jul 2024 14:31:11 -0400 > > > > Previously, project-kill-buffers always called (project-current t). A > > Lisp program could change what project project-kill-buffers operated > > on by binding project-current-directory-override. However, in some > > edge cases (for example, if the project was deleted between looking it > > up and calling project-kill-buffers) this might fail to detect a > > project, and so (project-current t) would prompt the user. > > > > To avoid this, accept the project to kill buffers for as an argument. > > That sounds like sweeping some minor bug under the carpet, or worse. > Why is it a good idea to silently second-guess what is TRT in these > marginal cases? Up front, I'd say asking the user is a safer bet. > > Suppose if some Lisp program runs (project-current t) to select a project to operate on, then does some > things, then runs project-kill-buffers. The p-k-b call should never prompt for a project again - it's intended to > operate on the project that was already selected. If the project that was already selected has disappeared, an > error is better than a confusing second prompt which might lead to the user selecting another different > project and killing all the buffers in that project. If the Lisp program wants to catch that error, it can. In my book, prompting the user with the like of Project FOO disappeared, continue killing its buffers? is better than silently doing the (potentially) wrong thing. IOW, when something that isn't supposed to happen did happen, let the human figure out the mess. Relying on project.el to signal an error is better, but might not be the best idea, either, because the error message is likely to be confusing and/or non-specific. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2024 15:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172062648325311 (code B ref 72019); Wed, 10 Jul 2024 15:49:02 +0000 Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 15:48:03 +0000 Received: from localhost ([127.0.0.1]:56966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRZY2-0006aB-N6 for submit@debbugs.gnu.org; Wed, 10 Jul 2024 11:48:03 -0400 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:38151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRZY0-0006Zd-6H for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 11:48:01 -0400 From: Spencer Baugh In-Reply-To: <8634ohnwpz.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 10 Jul 2024 17:32:56 +0300") References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> Date: Wed, 10 Jul 2024 11:47:48 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1720626468; bh=zg6Yq9+20fLQ/oz4EaN83mHMoo8FAuGba4/YLftDWtc=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=JqR97ZIUAZBC3o/SBqRhTVed302eWehnx2zwHmeEVydcoe1pMcVEMT+LFBOJS9w4s +HLnTZqIB1lvZ5RxPf2YxVcBaCwpp7fj1YFenAzLU2vJJxpCSfgOWE77Yo+5teDnW5 5J4Sb+NE/LfbkG4nEUYK60VTYioJG5owGOB7U2+cgkOmC5ME45tYPpQuRB4CX1soa+ F/Ya1QM+GbwBGP1lw6w3sWXH9Q34DP8WIay+QW/QqrkpJnebdG6ZRmjSUY0lFQTa89 NQnj2j29EkO+JRUtd2mJli8vIV76M/ShdH9QA9A1/1ZUEXlDkMyiFGzZUUUJmHQv67 fSdaGmG5CDT7Q== X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Spencer Baugh >> Date: Wed, 10 Jul 2024 09:27:06 -0400 >> Cc: 72019@debbugs.gnu.org >>=20 >> On Wed, Jul 10, 2024, 7:19=E2=80=AFAM Eli Zaretskii wrote: >>=20 >> > From: Spencer Baugh >> > Date: Tue, 09 Jul 2024 14:31:11 -0400 >> >=20 >> > Previously, project-kill-buffers always called (project-current t). A >> > Lisp program could change what project project-kill-buffers operated >> > on by binding project-current-directory-override. However, in some >> > edge cases (for example, if the project was deleted between looking it >> > up and calling project-kill-buffers) this might fail to detect a >> > project, and so (project-current t) would prompt the user. >> >=20 >> > To avoid this, accept the project to kill buffers for as an argument. >>=20 >> That sounds like sweeping some minor bug under the carpet, or worse. >> Why is it a good idea to silently second-guess what is TRT in these >> marginal cases? Up front, I'd say asking the user is a safer bet. >>=20 >> Suppose if some Lisp program runs (project-current t) to select a projec= t to operate on, then does some >> things, then runs project-kill-buffers. The p-k-b call should never pro= mpt for a project again - it's intended to >> operate on the project that was already selected. If the project that w= as already selected has disappeared, an >> error is better than a confusing second prompt which might lead to the u= ser selecting another different >> project and killing all the buffers in that project. If the Lisp progra= m wants to catch that error, it can. > > In my book, prompting the user with the like of > > Project FOO disappeared, continue killing its buffers? > > is better than silently doing the (potentially) wrong thing. IOW, > when something that isn't supposed to happen did happen, let the human > figure out the mess. Relying on project.el to signal an error is > better, but might not be the best idea, either, because the error > message is likely to be confusing and/or non-specific. Yes, that's all true. However, this is a minor edge case, which so far I've only observed happen once, and then it was only due to a user's bad configuration. I'd rather just signal an error for now (by avoiding the call to (project-current t)), which the current patch will do, since that improves on the situation without requiring us to invest more effort on something very rare. If it keeps happening, I'll send a future patch which further improves things. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2024 17:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172063275314692 (code B ref 72019); Wed, 10 Jul 2024 17:33:02 +0000 Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 17:32:33 +0000 Received: from localhost ([127.0.0.1]:57076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRbBB-0003ot-7p for submit@debbugs.gnu.org; Wed, 10 Jul 2024 13:32:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40010) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRbB8-0003of-HN for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 13:32:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRbAv-0006gr-0N; Wed, 10 Jul 2024 13:32:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=uoflJqjWSgQp6nRDdaEnQEZhEauPMc8SbL0bzFAHeMo=; b=q/s/pcQAWD4Do8f5uXI/ yk4F/hyoBe/sqaMxvI7w4HR1H5FVVIe0Ex5DBwKdzK6bdr/O3TpThgftroYSy8kGStYJ0UYM6Ik8m u05dtw68931skhewpoLpNVohb7Nz9DfYmAFe+/C1cbMq5g9tP18IWU/Iw3JWXZHBFnUJfT3O4sqcv JS+i+ZV6uFC3vnT+FLbswRPePjHEmyU8lIhuOH9bwBj6258FunLvpOiIBP+NoyfyDAY9LK09QNCNs chJ7tzNdVRszBbfOcXT2FMGG7eanzR0MRdy7NdcZEnAISzKZCEPrXcNHNaehKhMRaa/PMDumYxTPm n9XFeAAU9/OirA==; Date: Wed, 10 Jul 2024 20:32:12 +0300 Message-Id: <86zfqpm9ur.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 10 Jul 2024 11:47:48 -0400) References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: 72019@debbugs.gnu.org > Date: Wed, 10 Jul 2024 11:47:48 -0400 > > Eli Zaretskii writes: > > >> From: Spencer Baugh > >> Date: Wed, 10 Jul 2024 09:27:06 -0400 > >> Cc: 72019@debbugs.gnu.org > >> > >> On Wed, Jul 10, 2024, 7:19 AM Eli Zaretskii wrote: > >> > >> > From: Spencer Baugh > >> > Date: Tue, 09 Jul 2024 14:31:11 -0400 > >> > > >> > Previously, project-kill-buffers always called (project-current t). A > >> > Lisp program could change what project project-kill-buffers operated > >> > on by binding project-current-directory-override. However, in some > >> > edge cases (for example, if the project was deleted between looking it > >> > up and calling project-kill-buffers) this might fail to detect a > >> > project, and so (project-current t) would prompt the user. > >> > > >> > To avoid this, accept the project to kill buffers for as an argument. > >> > >> That sounds like sweeping some minor bug under the carpet, or worse. > >> Why is it a good idea to silently second-guess what is TRT in these > >> marginal cases? Up front, I'd say asking the user is a safer bet. > >> > >> Suppose if some Lisp program runs (project-current t) to select a project to operate on, then does some > >> things, then runs project-kill-buffers. The p-k-b call should never prompt for a project again - it's intended to > >> operate on the project that was already selected. If the project that was already selected has disappeared, an > >> error is better than a confusing second prompt which might lead to the user selecting another different > >> project and killing all the buffers in that project. If the Lisp program wants to catch that error, it can. > > > > In my book, prompting the user with the like of > > > > Project FOO disappeared, continue killing its buffers? > > > > is better than silently doing the (potentially) wrong thing. IOW, > > when something that isn't supposed to happen did happen, let the human > > figure out the mess. Relying on project.el to signal an error is > > better, but might not be the best idea, either, because the error > > message is likely to be confusing and/or non-specific. > > Yes, that's all true. However, this is a minor edge case, which so far > I've only observed happen once, and then it was only due to a user's bad > configuration. I'd rather just signal an error for now (by avoiding the > call to (project-current t)), which the current patch will do, since > that improves on the situation without requiring us to invest more > effort on something very rare. If we want to signal an error, let's signal an error, but with an explicit error message explaining the problem. Doing that by adding an argument sounds risky, since it doesn't target this specific situation, and so installing on the release branch is not necessarily justified. Are you okay with diagnosing this specific situation and signaling an error explicitly in the code? From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2024 17:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172063337615638 (code B ref 72019); Wed, 10 Jul 2024 17:43:02 +0000 Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 17:42:56 +0000 Received: from localhost ([127.0.0.1]:57092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRbLD-00044A-LB for submit@debbugs.gnu.org; Wed, 10 Jul 2024 13:42:56 -0400 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:49329) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRbLA-00043v-3s for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 13:42:53 -0400 From: Spencer Baugh In-Reply-To: <86zfqpm9ur.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 10 Jul 2024 20:32:12 +0300") References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <86zfqpm9ur.fsf@gnu.org> Date: Wed, 10 Jul 2024 13:42:40 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1720633360; bh=7FSyN3Kegqmi0k76zw35kNFAZQ4CfypOBDskG53M9/E=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=y0oPwNs5mm6EmphmwJVRExDWue12Y4Jw8gweAjat5Hr2qRBVzqkXUz9zmPMhE+Yec JfjV8y0aGQyP2XNNaDDSdydCm5e0Js0Qe5kLLXdoo9RT39SgvHR0fWIRZEpliomOz+ mOLB6RQ8hl3uzQhGmBVNAyilWeo1eb9b5estNfudprtvDGZezbDnNifClWFPSePyV2 KMfIZkj/Q/HHv9TqiTV0XWJo/ke1pm02/twiqT4LnNFLomCDfCM+WlJNOkPEn1tX3h F4gxpqEGoveiP6jr8fzI9KEn1LkV8T8uk/25f4W7Y7oj6QVAwRApyDC5jSVQJe+j3K OtT4SLfTudvHQ== X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: 72019@debbugs.gnu.org >> Date: Wed, 10 Jul 2024 11:47:48 -0400 >>=20 >> Eli Zaretskii writes: >>=20 >> >> From: Spencer Baugh >> >> Date: Wed, 10 Jul 2024 09:27:06 -0400 >> >> Cc: 72019@debbugs.gnu.org >> >>=20 >> >> On Wed, Jul 10, 2024, 7:19=E2=80=AFAM Eli Zaretskii wr= ote: >> >>=20 >> >> > From: Spencer Baugh >> >> > Date: Tue, 09 Jul 2024 14:31:11 -0400 >> >> >=20 >> >> > Previously, project-kill-buffers always called (project-current t)= . A >> >> > Lisp program could change what project project-kill-buffers operat= ed >> >> > on by binding project-current-directory-override. However, in some >> >> > edge cases (for example, if the project was deleted between lookin= g it >> >> > up and calling project-kill-buffers) this might fail to detect a >> >> > project, and so (project-current t) would prompt the user. >> >> >=20 >> >> > To avoid this, accept the project to kill buffers for as an argume= nt. >> >>=20 >> >> That sounds like sweeping some minor bug under the carpet, or worse. >> >> Why is it a good idea to silently second-guess what is TRT in these >> >> marginal cases? Up front, I'd say asking the user is a safer bet. >> >>=20 >> >> Suppose if some Lisp program runs (project-current t) to select a pro= ject to operate on, then does some >> >> things, then runs project-kill-buffers. The p-k-b call should never = prompt for a project again - it's intended to >> >> operate on the project that was already selected. If the project tha= t was already selected has disappeared, an >> >> error is better than a confusing second prompt which might lead to th= e user selecting another different >> >> project and killing all the buffers in that project. If the Lisp pro= gram wants to catch that error, it can. >> > >> > In my book, prompting the user with the like of >> > >> > Project FOO disappeared, continue killing its buffers? >> > >> > is better than silently doing the (potentially) wrong thing. IOW, >> > when something that isn't supposed to happen did happen, let the human >> > figure out the mess. Relying on project.el to signal an error is >> > better, but might not be the best idea, either, because the error >> > message is likely to be confusing and/or non-specific. >>=20 >> Yes, that's all true. However, this is a minor edge case, which so far >> I've only observed happen once, and then it was only due to a user's bad >> configuration. I'd rather just signal an error for now (by avoiding the >> call to (project-current t)), which the current patch will do, since >> that improves on the situation without requiring us to invest more >> effort on something very rare. > > If we want to signal an error, let's signal an error, but with an > explicit error message explaining the problem. Doing that by adding > an argument sounds risky, since it doesn't target this specific > situation, and so installing on the release branch is not necessarily > justified. Are you okay with diagnosing this specific situation and > signaling an error explicitly in the code? I don't need this to be on the release branch. I'd prefer to add the argument and just keep this on master. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2024 17:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172063409816814 (code B ref 72019); Wed, 10 Jul 2024 17:55:02 +0000 Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 17:54:58 +0000 Received: from localhost ([127.0.0.1]:57108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRbWs-0004N8-1i for submit@debbugs.gnu.org; Wed, 10 Jul 2024 13:54:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRbWn-0004Mt-4S for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 13:54:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRbWb-0002Ah-35; Wed, 10 Jul 2024 13:54:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=JM5MVLMCYBQHDxf1bLbfclKBCC05LLFLf6L4hH7DAnA=; b=B29PLSLkMEle tydEsPzGkpYZf2XnaNUNqNmBSKKwdy2vhaS26aBWo08IMmPRaR12XoRWJHgKwCTUCMo3E7IxVWX4F 0eOB14BuGKDTAeFOuL60U+b8t4HfgDE6HC1hbpfDzrXMFNy+lDHgmzR3iYLebS8snLFmjb0DYR7il OXKdePwROZW2mo/CvMaci3R9xtuTmUp313Tnq3jO2XrRzGTUwYgSJA4AAHNnPc2uAeUAcTbpoHwAj Ji410gaL4qtklm/qNubf9XRL5d70DONpB11VRVQLdFKS15RSbjf7wzxt6gzDZfJwH/U2GgPzV+Efm tuIkGLbJIuG7PKf4328BrQ==; Date: Wed, 10 Jul 2024 20:54:37 +0300 Message-Id: <86v81dm8te.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 10 Jul 2024 13:42:40 -0400) References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <86zfqpm9ur.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: 72019@debbugs.gnu.org > Date: Wed, 10 Jul 2024 13:42:40 -0400 > > > If we want to signal an error, let's signal an error, but with an > > explicit error message explaining the problem. Doing that by adding > > an argument sounds risky, since it doesn't target this specific > > situation, and so installing on the release branch is not necessarily > > justified. Are you okay with diagnosing this specific situation and > > signaling an error explicitly in the code? > > I don't need this to be on the release branch. I'd prefer to add the > argument and just keep this on master. Why do you prefer to add an argument? From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2024 18:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172063621920578 (code B ref 72019); Wed, 10 Jul 2024 18:31:01 +0000 Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 18:30:19 +0000 Received: from localhost ([127.0.0.1]:57140 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRc54-0005Lp-Tj for submit@debbugs.gnu.org; Wed, 10 Jul 2024 14:30:19 -0400 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:53505) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRc51-0005Lb-IL for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 14:30:17 -0400 From: Spencer Baugh In-Reply-To: <86v81dm8te.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 10 Jul 2024 20:54:37 +0300") References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <86zfqpm9ur.fsf@gnu.org> <86v81dm8te.fsf@gnu.org> Date: Wed, 10 Jul 2024 14:30:02 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1720636202; bh=h6PFbcellK3RH/1ecVr7ogrhZjXm/R5bEwArcWpaQPQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=yDv8p4SVRgAh0Zpua1KRUVDUY5402xHpWNK2+0jOkWtEDA1WKQrCw8/seCiMzlRgk /Fv4Qu7lr2LCawGno5zKHgfMhpGddW6ZYG1HwiZfAEvsalyVrMkxtXrMQ5rsleg/y0 NznbEq+ads10CrlmoyIfTju7X3NEPgSUjnfk5c4rRY1K1Qz3p3r8vKs6TVh3zKdn0z KhJPMptxJHhrZas55acdeptE7itC//sTtv9corqjKyl6mK/Eiy4OK50HLGTuKva+vo ZKoZQcXpX285xjESY1Tys9Y3v7X7nkNedkRAOlBGlfr1z/2ds8LNKTP770fN/W2bm4 J9xjlR3g6b0MQ== X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: 72019@debbugs.gnu.org >> Date: Wed, 10 Jul 2024 13:42:40 -0400 >> >> > If we want to signal an error, let's signal an error, but with an >> > explicit error message explaining the problem. Doing that by adding >> > an argument sounds risky, since it doesn't target this specific >> > situation, and so installing on the release branch is not necessarily >> > justified. Are you okay with diagnosing this specific situation and >> > signaling an error explicitly in the code? >> >> I don't need this to be on the release branch. I'd prefer to add the >> argument and just keep this on master. > > Why do you prefer to add an argument? Because it is also nicer to explicitly indicate what project the Lisp program is operating on. Going through project-current means there are a number of possible bugs. Lisp programs should pass in the project instance; this is preferred for new project.el-using code. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2024 19:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.17206380541929 (code B ref 72019); Wed, 10 Jul 2024 19:01:01 +0000 Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 19:00:54 +0000 Received: from localhost ([127.0.0.1]:57180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRcYg-0000V3-2K for submit@debbugs.gnu.org; Wed, 10 Jul 2024 15:00:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRcYc-0000Up-TY for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 15:00:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRcYQ-0005rM-Sl; Wed, 10 Jul 2024 15:00:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2kBAKzQAdlbkTx99dPgAeOMJ8Linnj7YmukN6qLnEGc=; b=kbT/1qSwly/M 1R025SKUnQc86sCd0DwHtmOh65X+Di/RCgXjoLpA9UTPglPMnnJc1JfwO7xwmBWuz3pG4FTRsglY3 RIf6ofNwITAnlRZy+Y5XB5xVkSUGsT7r6BFTum79s+5m3ffSU2UjbnJSK8z3TjYJNQi/LXQjX0mK/ jAS/GPgLstfh3fdeItvGPPLCSo7U0iwCyCxndm+ivO5ujj7qUam9qIQTBtA963XuKaPD6ToA1eoLK EnanXg53m07wbme+8ugv5SMc4hzLbY9DpgP1JMDbsQOWPG1uo5J/P5WTYweU7ZceH+wJubnWfH/EI asvZTimZe6MbUb7VCR3fCg==; Date: Wed, 10 Jul 2024 22:00:33 +0300 Message-Id: <86sewhm5ri.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 10 Jul 2024 14:30:02 -0400) References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <86zfqpm9ur.fsf@gnu.org> <86v81dm8te.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: 72019@debbugs.gnu.org > Date: Wed, 10 Jul 2024 14:30:02 -0400 > > Eli Zaretskii writes: > > >> I don't need this to be on the release branch. I'd prefer to add the > >> argument and just keep this on master. > > > > Why do you prefer to add an argument? > > Because it is also nicer to explicitly indicate what project the Lisp > program is operating on. Going through project-current means there are > a number of possible bugs. Lisp programs should pass in the project > instance; this is preferred for new project.el-using code. If this is the current trend in project.el development, then I have no objections to it. I find it a bit surprising that the original motivation for this was something completely different, though. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Jul 2024 00:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii , Spencer Baugh Cc: 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172065672124874 (code B ref 72019); Thu, 11 Jul 2024 00:12:02 +0000 Received: (at 72019) by debbugs.gnu.org; 11 Jul 2024 00:12:01 +0000 Received: from localhost ([127.0.0.1]:50552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRhPk-0006T8-Mh for submit@debbugs.gnu.org; Wed, 10 Jul 2024 20:12:00 -0400 Received: from fhigh2-smtp.messagingengine.com ([103.168.172.153]:45431) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRhPg-0006Ss-VI for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 20:11:58 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 3981F1140424; Wed, 10 Jul 2024 20:11:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 10 Jul 2024 20:11:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1720656712; x=1720743112; bh=pPUVkdjF65xJbB03fGDZuNkvN8rZQMMwTTfs9L+vFqo=; b= RUYtlxZtmQBKlF4NEK/aWioPANRCau52QAyBIp2uj1OXeb9vOpPmumDf06OR+jow o4cuDwkQydW997a12xpGWFo3X+8Tmd1Oes/okNqO96SkL4Ih32RXSg/yrPpmvUak N4Bd2mddQvhPxqpH0xzWDxwaCeBkeQRlAsHggplIWoYetx6Czn8B4ceTMBMSk8ga IdtjoPnfcvIUw1RkTs9sEcJfvQojbTkb0hqOf8Djya1Q1Ra2GBVPxgOp1C7bwE63 VJGZt89hZ6GYugBfuxaPjmy75pDjYAcRLUXxixsuaKaPTUm0xFFP/psVyCFS9+0O 7OR1VHGHFmjaNUYnXtAx3g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1720656712; x= 1720743112; bh=pPUVkdjF65xJbB03fGDZuNkvN8rZQMMwTTfs9L+vFqo=; b=h xLPRrWuebYLY4lWi4uFnCoFMCWRLX7YqGQG7oFGfgGAIXJWT19z9vQY5KYFBVekd LjnHDLrGCAG7yDVSprIivMpQMvox8uKh5thWQI+QKZCyd4GZdGAI8+TYB4q5W9gq d6acY+OuQcA+1QmpUlVU09K7pJwjre/K1+eAdSW7Symq7dp6xb2SYe39bymW3Gee 0LByFmtn4NFDz3VJr4Sfli28gbGctLkdL2xdaTqbTMHNpCBbROL46F1CuF4lSVjm wGZQQT3ar6plgmwci7w81KNx91oe8ynm2g5NgDuQLD/qSv0YBZ1aA1mwXbQjdPSH TUMC3l06CSesCkeSY6hsQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrfeefgdefvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudej heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 10 Jul 2024 20:11:50 -0400 (EDT) Message-ID: <0ce21379-70a7-4859-9f3f-2f88d23dccbc@gutov.dev> Date: Thu, 11 Jul 2024 03:11:46 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <8634ohnwpz.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 10/07/2024 17:32, Eli Zaretskii wrote: > In my book, prompting the user with the like of > > Project FOO disappeared, continue killing its buffers? Without a change like the proposed, we don't have access to any FOO (the hook simply will return nil), so that's not something the general code can do. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Jul 2024 00:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii , Spencer Baugh Cc: 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172065713825510 (code B ref 72019); Thu, 11 Jul 2024 00:19:02 +0000 Received: (at 72019) by debbugs.gnu.org; 11 Jul 2024 00:18:58 +0000 Received: from localhost ([127.0.0.1]:50566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRhWU-0006dO-00 for submit@debbugs.gnu.org; Wed, 10 Jul 2024 20:18:58 -0400 Received: from fhigh2-smtp.messagingengine.com ([103.168.172.153]:60039) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRhWS-0006d9-B3 for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 20:18:56 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 9B4521140AA4; Wed, 10 Jul 2024 20:18:51 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 10 Jul 2024 20:18:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1720657131; x=1720743531; bh=0GtM6Ogf50st+0BFiDpavtdExsiF0SClfpZAL65uYfM=; b= IpgecCjRHtj6q5G+DtOTuAcnnb0BGfLOQUqDV/Fw2EtYec4U7OABrgo1p/ORGUdr layMfwqYFB8lDdMnPWvtOkq/TzGYYrh1AhGusYAlIc5zBuiAvH7SAnRa/O3g+BwU oTNf1i8jUoXZDEdsu9sV+dSuB1E3aVxUVoaloQTbytht+/cla1C4BZc8yAq+gYeK 1w7hMrEymZcGLG9n35835R5YSe5X3l4mOUmiDaP8bfpTxGfhr//FeP/8u6EG3Vgi sgvxZdSvOOMTpNnS0UVOfMN5/Cim8TrY3I2IjnREF95zXj4l+m2ctsoZhDI2i/mu 1V0HFTNwTVWI/bVv3udEzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1720657131; x= 1720743531; bh=0GtM6Ogf50st+0BFiDpavtdExsiF0SClfpZAL65uYfM=; b=C 0tuvPo0ci9fPP0wqNXI0At0ijHYEqfq2LFn1T+8p5hoqRw8pK/7s10FGPv/7B7/b tZ3JWIGbZRYYhfkOFGFmo5cbkNWSRnxNAekWGnk4lcPztQCcZCug/qgII+KYcD8P OEAdnUxCskVHQexXrWgTg7v9FE/KLwxZG4sS+WJqBXV0k3TPK2IVtPMxmdJtLgWo m0Qsa1/BnuIFbvMIif9HnO8GS1lmcNl3OjgmrOZX1TrsJvv8h+LyI1cRRptNzXd9 cBy8m3uu3oUuZeOv+g4hhPWb6WlaYJJFz3PwsHT/ghsp/JnZjwH+a1f+87S17BaB T9jHr+BfipIyVjuIN4NZg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrfeefgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudej heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 10 Jul 2024 20:18:49 -0400 (EDT) Message-ID: <5c12905c-370e-419b-8ff1-657341da68cf@gutov.dev> Date: Thu, 11 Jul 2024 03:18:46 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <86zfqpm9ur.fsf@gnu.org> <86v81dm8te.fsf@gnu.org> <86sewhm5ri.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86sewhm5ri.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 10/07/2024 22:00, Eli Zaretskii wrote: >> Because it is also nicer to explicitly indicate what project the Lisp >> program is operating on. Going through project-current means there are >> a number of possible bugs. Lisp programs should pass in the project >> instance; this is preferred for new project.el-using code. > If this is the current trend in project.el development, then I have no > objections to it. I find it a bit surprising that the original > motivation for this was something completely different, though. I don't know if it's going to be a big direction, but the logic seems sound for a command like this. The original choice was more or less arbitrary. The change in the patch is backward-compatible, so it shouldn't hurt. The particular benefit scenario that I can see is this: * The project directory has been deleted, but a number of its buffers it still around. * So it doesn't seem feasible to compute the project instance automatically (the project markers are gone, etc). * But if something has held onto a project object, its method (project-buffers) might feasibly complete without errors. For project-kill-buffers in particular it seems like a real advantage - getting to clean up buffers belonging to an already deleted project. And if one step 2 or 3 fails with an error, oh well, it doesn't seem like we could have done better. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Jul 2024 04:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172067342617711 (code B ref 72019); Thu, 11 Jul 2024 04:51:02 +0000 Received: (at 72019) by debbugs.gnu.org; 11 Jul 2024 04:50:26 +0000 Received: from localhost ([127.0.0.1]:50710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRllB-0004bb-TN for submit@debbugs.gnu.org; Thu, 11 Jul 2024 00:50:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51520) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRll9-0004bO-7C for 72019@debbugs.gnu.org; Thu, 11 Jul 2024 00:50:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRll4-0006Jw-2P; Thu, 11 Jul 2024 00:50:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Gi20eMID54lPXCaCRxaIT4+9lopIFxNDe0hvkvj+rKQ=; b=B3UoVa7/lwGw oPNMl1AUDBr9X/FIPWUjNOhqfeU/dAwVUbkZwmxk3aMokV0d5/DOdiwufIwT5Hfk1pRyb3TaoMlYl 3wgaRPf5LrE03qIm/ox1S/1Zp6suxmcnhrzJRG4eFg0aZqg5B2MLqzGRaaPxzV/8ORQSj4JvWEa3L Mve7WFlNwW1kpNURG8ibjgbRN9ZWfwDQff8OB9Ajrevns/8z4KDnCayb9Mut75kVZnKw007b8ve1j rJ0fZ2xmqDiDAPDJ4++l6NliwcbeHJFlpOmZfRT89dTxW+oU05uxdEexzfQmABz26o2Vo9QoA6t1T BBP0l0OsoHGedQkAT5voIg==; Date: Thu, 11 Jul 2024 07:50:04 +0300 Message-Id: <86le28mt1f.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <0ce21379-70a7-4859-9f3f-2f88d23dccbc@gutov.dev> (message from Dmitry Gutov on Thu, 11 Jul 2024 03:11:46 +0300) References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <0ce21379-70a7-4859-9f3f-2f88d23dccbc@gutov.dev> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 11 Jul 2024 03:11:46 +0300 > Cc: 72019@debbugs.gnu.org > From: Dmitry Gutov > > On 10/07/2024 17:32, Eli Zaretskii wrote: > > In my book, prompting the user with the like of > > > > Project FOO disappeared, continue killing its buffers? > > Without a change like the proposed, we don't have access to any FOO (the > hook simply will return nil), so that's not something the general code > can do. That's a minor issue that can be easily handled by fine-tuning the message. For example: Current project disappeared, continue killing its buffers? From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Jul 2024 04:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172067358717948 (code B ref 72019); Thu, 11 Jul 2024 04:54:02 +0000 Received: (at 72019) by debbugs.gnu.org; 11 Jul 2024 04:53:07 +0000 Received: from localhost ([127.0.0.1]:50715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRlnn-0004fQ-C9 for submit@debbugs.gnu.org; Thu, 11 Jul 2024 00:53:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRlnk-0004ev-Iy for 72019@debbugs.gnu.org; Thu, 11 Jul 2024 00:53:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRlnf-0008PZ-Ot; Thu, 11 Jul 2024 00:52:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=k6h3uckj7zD/TduapC8SkLUzg7PMIHvOdGq3a0HxoFo=; b=QYMH3b2IY4Ov +nuCoFE2d/6zIufooxPh5d0H/S+5bjhOR/lUFo4Fb5mX6hUCVVMLKvERePgU4VOTpeBjv5GTyBl8W HiUBuogs4ivIfRABjDk4SmIc8KHYdWWykCdFcN8ohV/BUAqCpeZKCHSEE3fXdY36gIDldq+LviSYz KNI7E9vppA+Ps2Rh0ku1sqPmBM1XJj9xl3Qwr+blMTinrEUgiDmC/G2SxOirlEc6BCcWEYeFi2teO SFcxcvs0Mb9VHo5tlTQ6S54fERPa2rwdma0HXzDue9rinH3bNHQA+HtxfPjfsN+AJBu0EJxME84A1 tk7RSBOLvgn0QsY/Lu2c9A==; Date: Thu, 11 Jul 2024 07:52:56 +0300 Message-Id: <86jzhsmswn.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <5c12905c-370e-419b-8ff1-657341da68cf@gutov.dev> (message from Dmitry Gutov on Thu, 11 Jul 2024 03:18:46 +0300) References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <86zfqpm9ur.fsf@gnu.org> <86v81dm8te.fsf@gnu.org> <86sewhm5ri.fsf@gnu.org> <5c12905c-370e-419b-8ff1-657341da68cf@gutov.dev> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 11 Jul 2024 03:18:46 +0300 > Cc: 72019@debbugs.gnu.org > From: Dmitry Gutov > > On 10/07/2024 22:00, Eli Zaretskii wrote: > >> Because it is also nicer to explicitly indicate what project the Lisp > >> program is operating on. Going through project-current means there are > >> a number of possible bugs. Lisp programs should pass in the project > >> instance; this is preferred for new project.el-using code. > > If this is the current trend in project.el development, then I have no > > objections to it. I find it a bit surprising that the original > > motivation for this was something completely different, though. > > I don't know if it's going to be a big direction, but the logic seems > sound for a command like this. > > The original choice was more or less arbitrary. The change in the patch > is backward-compatible, so it shouldn't hurt. > > The particular benefit scenario that I can see is this: > > * The project directory has been deleted, but a number of its buffers it > still around. > * So it doesn't seem feasible to compute the project instance > automatically (the project markers are gone, etc). > * But if something has held onto a project object, its method > (project-buffers) might feasibly complete without errors. > > For project-kill-buffers in particular it seems like a real advantage - > getting to clean up buffers belonging to an already deleted project. And > if one step 2 or 3 fails with an error, oh well, it doesn't seem like we > could have done better. My question for this scenario would be: does project.el support it in general? I'd expect quite a few of the functions to rely on the fact that the project directory is there, in which case this is the tip of a very large iceberg. But you know the code and the design much better than I do, so if it makes sense to you, fine. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Jul 2024 19:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: sbaugh@janestreet.com, 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.17207271084656 (code B ref 72019); Thu, 11 Jul 2024 19:46:01 +0000 Received: (at 72019) by debbugs.gnu.org; 11 Jul 2024 19:45:08 +0000 Received: from localhost ([127.0.0.1]:52598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRzj1-0001D1-Ph for submit@debbugs.gnu.org; Thu, 11 Jul 2024 15:45:08 -0400 Received: from fhigh6-smtp.messagingengine.com ([103.168.172.157]:45787) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRziy-0001CB-NU for 72019@debbugs.gnu.org; Thu, 11 Jul 2024 15:45:06 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfhigh.nyi.internal (Postfix) with ESMTP id BD6D91140343; Thu, 11 Jul 2024 15:44:59 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 11 Jul 2024 15:44:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1720727099; x=1720813499; bh=hYU2m4TYbc1IaAH0Iuw9zE79HYIRtT9Qisb541d22Lg=; b= Uj0t3LZykkWky9/49PLjWxpUNEf/QaRFvIK7RAeWD/oN5pUL+wPBsMcyLwWzw9/N 5aKF/5zvcrTIL3lPDuLFk5E52YHSD2RiThGkz7j7q6uEUYUD95MGrYcH12+djqtj 5Y/9SjwyihWY2E6VDdsftw+BvUw5Zbnzzl1uTMumvcGzUBzjnJfBxazuMIMQ1xf4 XFnhN2zBVASkDL6mLIzyoZoSGxN0xEwq/RdCh5Fvj/JQ9XVmuJNBFmA169oad3uE COe+qcMK4VKKpyYeS4peIQmwcXrscVK5WsK5m1eXzqnAzx2H3cnJv0ASQgMS1UGB rObiWHdKXi31yieiDfxBGw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1720727099; x= 1720813499; bh=hYU2m4TYbc1IaAH0Iuw9zE79HYIRtT9Qisb541d22Lg=; b=M SL9CipScArO79b5dRUiZIB0UpE/QHMhDEFQWNXbI0GVSRgIwV9nzO1rncAIU6Fso tbt30+HIvIbg2W+Bs7Aeta45Lj22PMUTYsEQEdOzMv0fdKpHuByndQyvf8BgxDwy L40dgF8TQt8WuBVubw8wxyuOqPxq2dl3tYBWGIGs3IQbG3HrVsSFPFwwXkMX7plV Wsk2fKGvovmzzA5XNwkvYl00/82vc5FKe85xPYedepOvWY9Cwb4xkwyweGzz1F4L yGGSKoc3HJgaaHGQ6hp1lpif29oe7FoRuWGnjCGE9wggBLKVPv86qe6a23CjKWQn t6rJa+Gb6YPUlp7JVq3Tg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrfeeggddugedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 11 Jul 2024 15:44:57 -0400 (EDT) Message-ID: <2d23e8f6-0891-4190-818a-c86861f58303@gutov.dev> Date: Thu, 11 Jul 2024 22:44:55 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <0ce21379-70a7-4859-9f3f-2f88d23dccbc@gutov.dev> <86le28mt1f.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86le28mt1f.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 11/07/2024 07:50, Eli Zaretskii wrote: >> Date: Thu, 11 Jul 2024 03:11:46 +0300 >> Cc:72019@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 10/07/2024 17:32, Eli Zaretskii wrote: >>> In my book, prompting the user with the like of >>> >>> Project FOO disappeared, continue killing its buffers? >> Without a change like the proposed, we don't have access to any FOO (the >> hook simply will return nil), so that's not something the general code >> can do. > That's a minor issue that can be easily handled by fine-tuning the > message. For example: > > Current project disappeared, continue killing its buffers? We would basically never be killing "its" buffers after that - so the proposed message seems misleading. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 Jul 2024 19:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: sbaugh@janestreet.com, 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.17207272865024 (code B ref 72019); Thu, 11 Jul 2024 19:49:02 +0000 Received: (at 72019) by debbugs.gnu.org; 11 Jul 2024 19:48:06 +0000 Received: from localhost ([127.0.0.1]:52611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRzlu-0001Iy-AT for submit@debbugs.gnu.org; Thu, 11 Jul 2024 15:48:06 -0400 Received: from fout2-smtp.messagingengine.com ([103.168.172.145]:60727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRzls-0001IS-Sk for 72019@debbugs.gnu.org; Thu, 11 Jul 2024 15:48:05 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id E47881381181; Thu, 11 Jul 2024 15:47:59 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 11 Jul 2024 15:47:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1720727279; x=1720813679; bh=DkLCKkT96aemKgm3cu4yFix3JgnT9skSrYjop8ARuzc=; b= r9cftYlaJzkTnydvQ9tRH8opHCRPZ/yh2kYUfgEyCuOYR+ejmC6mUS6aP/QyasIZ 34UQxTKFmt9gQQSUfQMfO3xNZfm8rV9zQbL27q1HmZAS2cZou7xZ7Sh9T6X+t7vP x8zSsB7bqcnQSwL1QScwa4Ndnq4ZC5MyIlVI3USYMQXzJ3dHUXIsefWwHiCOrZFK JdRSoJ/t0htUwAcbGsbJDsc4k+gC0YljJtR/PoebEFbWS5oiQgf6JIXSeqEw+tpw hgpBZv2QkCq4fgOg96Ywx01sE9ZC3kMRq+7V3yMQibljLD6j/8hYPokxmM4Xl2wz tLZ6QW2nj2ohwBPpBiTTHA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1720727279; x= 1720813679; bh=DkLCKkT96aemKgm3cu4yFix3JgnT9skSrYjop8ARuzc=; b=D QEPIzZTC0c48VKYBap5xDfHHvtsERFhIuOIpwtrghnhcJPkHk/Um6x/jZQjWNm7I fmtKNycHKGi07AEO8iA8vrCewmIFtGXAZexpMXTQf0K92pr7jh38R9ZVp/uPaGnR TVbWvYeHD6eSP1n4Cl55EXLimQE9tJmYrwWTKA9HpEkrEQusV9VKvL3Vv+q6xfWD /skPJMGZY4Q8LWbWTJ0F9vW5HJh64sGbTN3DIN0aO1vxWxaZTwYPg9mv8EUWuPrF 47zd2YyJe1k57tmN0R9WGiJ9rGNkUP/jmsTJNQ8ODCQydsDR7ttemFqX/3jSl6jZ Ff+ruQn06FxiCx9uwVNRw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrfeeggddugedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 11 Jul 2024 15:47:58 -0400 (EDT) Message-ID: <8935da89-8354-491b-9ee4-c76a26cea932@gutov.dev> Date: Thu, 11 Jul 2024 22:47:57 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <86zfqpm9ur.fsf@gnu.org> <86v81dm8te.fsf@gnu.org> <86sewhm5ri.fsf@gnu.org> <5c12905c-370e-419b-8ff1-657341da68cf@gutov.dev> <86jzhsmswn.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86jzhsmswn.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 11/07/2024 07:52, Eli Zaretskii wrote: >> For project-kill-buffers in particular it seems like a real advantage - >> getting to clean up buffers belonging to an already deleted project. And >> if one step 2 or 3 fails with an error, oh well, it doesn't seem like we >> could have done better. > > My question for this scenario would be: does project.el support it in > general? I'd expect quite a few of the functions to rely on the fact > that the project directory is there, in which case this is the tip of > a very large iceberg. I'm not sure. Hence I'm not announcing a big switchover for every command, or anything like that. But the command "kill all buffers" seems like a very good fit for a project that's not there anymore. > But you know the code and the design much better than I do, so if it > makes sense to you, fine. This particular decision is ad-hoc, but it does seem like it has no or very little drawbacks. Let me know if it's okay for emacs-30, or we should postpone it to master. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2024 05:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.17207634031191 (code B ref 72019); Fri, 12 Jul 2024 05:51:02 +0000 Received: (at 72019) by debbugs.gnu.org; 12 Jul 2024 05:50:03 +0000 Received: from localhost ([127.0.0.1]:52998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sS9AR-0000J7-FN for submit@debbugs.gnu.org; Fri, 12 Jul 2024 01:50:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sS9AO-0000IU-Qw for 72019@debbugs.gnu.org; Fri, 12 Jul 2024 01:50:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sS98C-0008Cb-Cp; Fri, 12 Jul 2024 01:47:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=shNrtAR/osNcLLTqGw31WnrYQpmR4CuIW96flNsJyxE=; b=lVnL4SV2vg/r 6fiZ290CCFU4ZdepRpdOzRY1AjVOOTHcwzC3BKotGAOF3GPOOZVF/Q5PvXO0XUQvWCDuplyDJdNJY OQBzQ1FsImEmxxKIlT1qFnuBV2lvyoTEsi4HvTdMfERb7Oc0k8hazBMkqUZjqTq55ujlGkkFoO9hy ObmV4UTF7Tmk9DeIu1QNF8lpIvXpFn4vtlKWi3ZTCG3/5mBDfKynjnxgu3jQunL7bMk+o50lkUJJu bDwYhTCWb9atvHFyTPoiRlQA+8ElSzr1kB5+Vm/Np/iIcJ2sgPRYDC3kTDApEJh8Cw6MWJIXiBvCD xKuvnoV2dBHlcPfamNK6bQ==; Date: Fri, 12 Jul 2024 08:47:14 +0300 Message-Id: <8634ofmaal.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <2d23e8f6-0891-4190-818a-c86861f58303@gutov.dev> (message from Dmitry Gutov on Thu, 11 Jul 2024 22:44:55 +0300) References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <0ce21379-70a7-4859-9f3f-2f88d23dccbc@gutov.dev> <86le28mt1f.fsf@gnu.org> <2d23e8f6-0891-4190-818a-c86861f58303@gutov.dev> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 11 Jul 2024 22:44:55 +0300 > Cc: sbaugh@janestreet.com, 72019@debbugs.gnu.org > From: Dmitry Gutov > > On 11/07/2024 07:50, Eli Zaretskii wrote: > >> Date: Thu, 11 Jul 2024 03:11:46 +0300 > >> Cc:72019@debbugs.gnu.org > >> From: Dmitry Gutov > >> > >> On 10/07/2024 17:32, Eli Zaretskii wrote: > >>> In my book, prompting the user with the like of > >>> > >>> Project FOO disappeared, continue killing its buffers? > >> Without a change like the proposed, we don't have access to any FOO (the > >> hook simply will return nil), so that's not something the general code > >> can do. > > That's a minor issue that can be easily handled by fine-tuning the > > message. For example: > > > > Current project disappeared, continue killing its buffers? > > We would basically never be killing "its" buffers after that - so the > proposed message seems misleading. Feel free to propose a different text. My main point is that it should not be too hard to come up with a message that is both accurate and helpful, in the sense that the user can decide what to do in this situation. From unknown Sat Jun 21 12:16:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jul 2024 05:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 72019@debbugs.gnu.org Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.17207634581275 (code B ref 72019); Fri, 12 Jul 2024 05:51:02 +0000 Received: (at 72019) by debbugs.gnu.org; 12 Jul 2024 05:50:58 +0000 Received: from localhost ([127.0.0.1]:53002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sS9BJ-0000KU-S5 for submit@debbugs.gnu.org; Fri, 12 Jul 2024 01:50:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sS9BI-0000KG-2T for 72019@debbugs.gnu.org; Fri, 12 Jul 2024 01:50:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sS996-0000DC-If; Fri, 12 Jul 2024 01:48:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=RkPzIAQRpUV3Cp3hb2xj/DRdUan2oEDMQOEhGgKpBzU=; b=lZvs0287DQnX nCMvp36hrKPX7k5tTHUdT04/nShmDNpzP3TgQIn6FOn3XvCJl0iHb2PxCXxBgcu2P6JByJ9ymokUV fAiSMapre+Gq7v11iwl99PytUrCkggnWSRhbieyKGOmov9lLgNY5eNurklIfcntgVfoXWHNu3JIyc n5R7z/cFtEWEmeCTdIYfc2hr0ju//H9dGb3zIMK2qNK1r2gBtc9+Dm8AxfsRslE8/pair0Vb5K3te 6pEDsl3CgKFCAMzO30g+Ug2FkUC0FMR8i/snndlQhnOmQlbfTMRTIPZf5hyCfzwqWOsTDgklrrO7t Bm8tKKABMGwZksFE3hVo9Q==; Date: Fri, 12 Jul 2024 08:48:37 +0300 Message-Id: <861q3zma8a.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8935da89-8354-491b-9ee4-c76a26cea932@gutov.dev> (message from Dmitry Gutov on Thu, 11 Jul 2024 22:47:57 +0300) References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <86zfqpm9ur.fsf@gnu.org> <86v81dm8te.fsf@gnu.org> <86sewhm5ri.fsf@gnu.org> <5c12905c-370e-419b-8ff1-657341da68cf@gutov.dev> <86jzhsmswn.fsf@gnu.org> <8935da89-8354-491b-9ee4-c76a26cea932@gutov.dev> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 11 Jul 2024 22:47:57 +0300 > Cc: sbaugh@janestreet.com, 72019@debbugs.gnu.org > From: Dmitry Gutov > > Let me know if it's okay for emacs-30, or we should postpone it to master. I prefer master. From unknown Sat Jun 21 12:16:22 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Spencer Baugh Subject: bug#72019: closed (Re: bug#72019: [PATCH] Add project argument to project-kill-buffers) Message-ID: References: <6cdbd7fb-eada-4ada-9366-b232e991ea67@gutov.dev> X-Gnu-PR-Message: they-closed 72019 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: patch Reply-To: 72019@debbugs.gnu.org Date: Tue, 16 Jul 2024 02:02:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1721095322-6636-1" This is a multi-part message in MIME format... ------------=_1721095322-6636-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #72019: [PATCH] Add project argument to project-kill-buffers which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 72019@debbugs.gnu.org. --=20 72019: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D72019 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1721095322-6636-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 72019-done) by debbugs.gnu.org; 16 Jul 2024 02:01:05 +0000 Received: from localhost ([127.0.0.1]:60653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sTXV2-0001hu-S7 for submit@debbugs.gnu.org; Mon, 15 Jul 2024 22:01:05 -0400 Received: from fout1-smtp.messagingengine.com ([103.168.172.144]:55367) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sTXV1-0001hK-7H for 72019-done@debbugs.gnu.org; Mon, 15 Jul 2024 22:01:03 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.nyi.internal (Postfix) with ESMTP id BDDA31388C91; Mon, 15 Jul 2024 22:00:55 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 15 Jul 2024 22:00:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1721095255; x=1721181655; bh=Xy80oMvtxJMJI9xatcvun2ZZ2HhQYN47GYAWpozkvpc=; b= Kq+bveJCQHkAT+5IoaU6F45Cbv2bWpIyH1O0cWNmNofALbpIsjvdMEfV5FTaJ/kn CZGlBGzab+qdlixTM1DF7SNDAUnoVx1f3JNN38t7OTD5HXKNqgEfG/5rgFqwkbbv /ls+1+UEA66KOEEypvdOkPiZrbsCcxGM18qPO6cJjx9DhNsFybQuVWRxv34pCfa6 80SnWsRZPmhAJI90KWFQoPJ595Uqul9mUpsj8S5Axgth70dOmAyOSEvFIrrbZFvm 8riCFvdgwWnmX+flKA9QJrzDxJsdV/cR/HyktsYS9jUq2oF1a0sTWRL3xU4zz2eD 3rMKl1lJ7rtyqAVpmj61eA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1721095255; x= 1721181655; bh=Xy80oMvtxJMJI9xatcvun2ZZ2HhQYN47GYAWpozkvpc=; b=W JljjSNqs45ZrLLF/jHsKOUiIINaysVs1AAmFVkJNZvSnoGiZN0eamZT3vEkBMQXC TJUmmMINklrJhjna8+NPTC8IAAEpv723RSrp0i+un61WGkib5nUbOTayeHq6EG6T ovttM4441TdQcL3dQNdFx2PMMJunpHthlogSWGs03PDu6U9O7ECyCyq+7+f0W6rS TQPfWEZM8zXJz1gIg5pKzZc/6FBm2bgF4NTe9IlbnA3WYVuL/4DbkIKcyje12JDh xNj8UxZskt/zV6ul4MiLmr2erk/9pLiXLrYX2vGBt1B4doGvJzFe9In6aaXq9VJu qFL88AQFVeEtV21ZrtsFA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrgeefgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudej heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 15 Jul 2024 22:00:53 -0400 (EDT) Message-ID: <6cdbd7fb-eada-4ada-9366-b232e991ea67@gutov.dev> Date: Tue, 16 Jul 2024 05:00:50 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers To: Eli Zaretskii References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <86zfqpm9ur.fsf@gnu.org> <86v81dm8te.fsf@gnu.org> <86sewhm5ri.fsf@gnu.org> <5c12905c-370e-419b-8ff1-657341da68cf@gutov.dev> <86jzhsmswn.fsf@gnu.org> <8935da89-8354-491b-9ee4-c76a26cea932@gutov.dev> <861q3zma8a.fsf@gnu.org> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <861q3zma8a.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 72019-done Cc: sbaugh@janestreet.com, 72019-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 12/07/2024 08:48, Eli Zaretskii wrote: >> Date: Thu, 11 Jul 2024 22:47:57 +0300 >> Cc:sbaugh@janestreet.com,72019@debbugs.gnu.org >> From: Dmitry Gutov >> >> Let me know if it's okay for emacs-30, or we should postpone it to master. > I prefer master. Thank you, now pushed to master, and closing. Let's see if any problems come up with this solution. ------------=_1721095322-6636-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 9 Jul 2024 18:31:28 +0000 Received: from localhost ([127.0.0.1]:54054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRFcd-0002Zf-J7 for submit@debbugs.gnu.org; Tue, 09 Jul 2024 14:31:28 -0400 Received: from lists.gnu.org ([209.51.188.17]:47792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRFcb-0002ZX-EQ for submit@debbugs.gnu.org; Tue, 09 Jul 2024 14:31:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRFcU-0003EF-7b for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 14:31:18 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRFcS-0006YE-Ev for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 14:31:17 -0400 From: Spencer Baugh To: bug-gnu-emacs@gnu.org Subject: [PATCH] Add project argument to project-kill-buffers Date: Tue, 09 Jul 2024 14:31:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1720549871; bh=sEpLYNVU6XtDRC99KdGm6vKpGtP0L0wnVakZ/3pphu8=; h=From:To:Subject:Date; b=AYBp5hIZzhgqbK9MTVOCeO6242k94bGjvlJpe1gz2GRRQleAy4m23Xwbk2Sw1yqCJ vDEAlwGdxDijlmkzsbYBtwrTxEfLJFg4aoxWXOH6SKiBJOOCSIbl83rnSRW0sCnRRb JlQ3DjGL/8VlOba/ErSpDsK2aA0gk9CS9tc9pE0QbmT8okA3BunXXsAAmjJJyvQtHx bVqeCvyvypq3iwNlGh+CioDW/G57UT9N+Osdo6vULSR3u2amc5M+6Rc5H1AQ5vpttr fCeAjvxHkow9jDyRrJ0rNEkBdUCGyiYHJqSXr/MUcQUAooiTg77rTO2mtmVCXDmgQP 36ki+Uk80HLyA== Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) --=-=-= Content-Type: text/plain Tags: patch Previously, project-kill-buffers always called (project-current t). A Lisp program could change what project project-kill-buffers operated on by binding project-current-directory-override. However, in some edge cases (for example, if the project was deleted between looking it up and calling project-kill-buffers) this might fail to detect a project, and so (project-current t) would prompt the user. To avoid this, accept the project to kill buffers for as an argument. * lisp/progmodes/project.el (project-kill-buffers): Take project as an optional argument. In GNU Emacs 29.2.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2024-06-01 built on igm-qws-u22796a Repository revision: fcef787a846f0c51f7443dfab6af6e18b476b166 Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.10 (Green Obsidian) Configured using: 'configure --with-x-toolkit=lucid --without-gpm --without-gconf --without-selinux --without-imagemagick --with-modules --with-gif=no --with-cairo --with-rsvg --without-compress-install --with-native-compilation=aot --with-tree-sitter PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-Add-project-argument-to-project-kill-buffers.patch >From 5fdd9735148a5b009c0a2a4339c88bf8ab177f37 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Tue, 9 Jul 2024 14:30:27 -0400 Subject: [PATCH] Add project argument to project-kill-buffers Previously, project-kill-buffers always called (project-current t). A Lisp program could change what project project-kill-buffers operated on by binding project-current-directory-override. However, in some edge cases (for example, if the project was deleted between looking it up and calling project-kill-buffers) this might fail to detect a project, and so (project-current t) would prompt the user. To avoid this, accept the project to kill buffers for as an argument. * lisp/progmodes/project.el (project-kill-buffers): Take project as an optional argument. --- lisp/progmodes/project.el | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index b7c1698f50b..3d0f742c51d 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1715,7 +1715,7 @@ project--buffers-to-kill bufs)) ;;;###autoload -(defun project-kill-buffers (&optional no-confirm) +(defun project-kill-buffers (&optional no-confirm project) "Kill the buffers belonging to the current project. Two buffers belong to the same project if their project instances, as reported by `project-current' in each buffer, are @@ -1725,9 +1725,11 @@ project-kill-buffers NO-CONFIRM is always nil when the command is invoked interactively. +If PROJECT is non-nil, kill buffers for that project instead. + Also see the `project-kill-buffers-display-buffer-list' variable." (interactive) - (let* ((pr (project-current t)) + (let* ((pr (or project (project-current t))) (bufs (project--buffers-to-kill pr)) (query-user (lambda () (yes-or-no-p -- 2.39.3 --=-=-=-- ------------=_1721095322-6636-1--