From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2023 21:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 66993@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.169939253632547 (code B ref -1); Tue, 07 Nov 2023 21:29:02 +0000 Received: (at submit) by debbugs.gnu.org; 7 Nov 2023 21:28:56 +0000 Received: from localhost ([127.0.0.1]:43437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0Td1-0008St-RE for submit@debbugs.gnu.org; Tue, 07 Nov 2023 16:28:56 -0500 Received: from lists.gnu.org ([2001:470:142::17]:42192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0Tcz-0008Sf-0G for submit@debbugs.gnu.org; Tue, 07 Nov 2023 16:28:53 -0500 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 1r0TcG-0004aa-H8 for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 16:28:08 -0500 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 1r0TcE-0005Ay-Sf for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 16:28:08 -0500 From: Spencer Baugh Date: Tue, 07 Nov 2023 16:28:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) 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: -0.1 (/) --=-=-= Content-Type: text/plain Tags: patch This fixes a periodic issue that happens with multiple Emacs instances and project.el. Maybe this isn't the right way to change the behavior of ask-user-about-lock though; possibly we should add some new defcustom to customize it. Happy to do that if that's preferred. In GNU Emacs 29.1.50 (build 15, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2023-10-25 built on igm-qws-u22796a Repository revision: 5cbca757f620c7b4ca31776711a247b8f266c36e Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.8 (Green Obsidian) Configured using: 'configure --config-cache --with-x-toolkit=lucid --with-gif=ifavailable' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-project.el-avoid-asking-user-about-project-list-file.patch >From ec6caaf9fcb913847278f7183e46d3026c6986fb Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Tue, 7 Nov 2023 16:24:26 -0500 Subject: [PATCH] project.el: avoid asking user about project-list-file lock There are several features which will cause Emacs to frequently call project-current, and therefore call project-remember-project, and therefore sometimes call project--write-project-list whenever a new project is seen. - project-uniquify-dirname-transform will call this for each new buffer - project-mode-line will call this on mode-line update - My own private project-watch will call this based on file-notify events. If a user has multiple Emacs instances open using one or more of these features, it's fairly easy for both of the Emacs instances to see a new project at the same time. In that case, they'll both call project--write-project-list at the same time, which will clash and run ask-user-about-lock. This will happen frequently if the user is often looking at new projects. There's no correct answer the user can give to ask-user-about-lock: either way, one of the Emacs instances will have its project-list-file update lost. So let's not even bother prompting the user: just do nothing if project-list-file is currently locked. In the long run, the update doesn't actually get lost, because the Emacs instance will probably make the same project-list-file update again a few seconds later due to a later call to project-current. So this doesn't lose anything. * lisp/progmodes/project.el (project--write-project-list): No-op if the file is locked. --- lisp/progmodes/project.el | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 43c78f8b16b..78aaa75de5f 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1719,7 +1719,13 @@ project--write-project-list (expand-file-name name))))) project--list) (current-buffer))) - (write-region nil nil filename nil 'silent)))) + ;; If project-list-file is locked by some other Emacs, fail to + ;; write rather than prompting the user. + (ignore-error file-locked + (cl-letf (((symbol-function 'ask-user-about-lock) + (lambda (file opponent) + (signal 'file-locked (list file opponent))))) + (write-region nil nil filename nil 'silent)))))) ;;;###autoload (defun project-remember-project (pr &optional no-write) -- 2.39.3 --=-=-=-- From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 00:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh , 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169940310319544 (code B ref 66993); Wed, 08 Nov 2023 00:26:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 00:25:03 +0000 Received: from localhost ([127.0.0.1]:43758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0WNT-00055A-Az for submit@debbugs.gnu.org; Tue, 07 Nov 2023 19:25:03 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:45797) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0WNP-00054X-PR for 66993@debbugs.gnu.org; Tue, 07 Nov 2023 19:25:02 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1A2105C00A6; Tue, 7 Nov 2023 19:24:16 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 07 Nov 2023 19:24:16 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1699403056; x=1699489456; bh=WFjNGQp5wP+GHv+Ereg0FwS3zBVKSJ03vy9 Qa767QzU=; b=i3gMzJ9DxCKDi4sLCMgW+G6XiXAncr+YQcdxh+UTZLRQ6J9CQWh EW3vwqNv6zBzYNqlQGGW/lxgDOBEiat72KCT9NlxS1DFfWGLse5ufQ1sRu3Y+OgK kS9W7jJ1IHrq4bH+1OVm+RGOqjNaPyBAORuz5MCcClNUeMHbUPtA0es75OZQMGLb nvYjlqcq5P/om8tIXk7bmwD5QtGBdEmfoUjLvsBWrg1ZcsDIQQJukAKS/yIhALcu C/S7vzjTBb+mY4aUYuivI409AOnOvvJL0tNoIjOrHyDzG3S/WB8xtc2V9NbShKwA RfZpX2vr5g2yDNPAohSR8jXZ6YTUjCPuIuw== 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:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1699403056; x= 1699489456; bh=WFjNGQp5wP+GHv+Ereg0FwS3zBVKSJ03vy9Qa767QzU=; b=H 8pFkS/K5lVpUH7r4shnXYWvkNefgglXRl4TZdeiUJLXTmT3n+Fvv331n6+yYuzBW 7F0us0hZ9HhcU22+KhP6g5Zuu7dGEaeUwnNyR8P9fFhtzin7HUBq7pigmoHQuzIf KnIzuxLdniWZO24LZWt7NH2P6Lu4lCu9b5KSO2tuHwHQjr3T5NnhytIMLeFoTArh /oygEAVKl3X5RodDDOMXU+LOKvRWQrioqM42LDOlzVjHGYIslal/HLQIeatliJ6g 0ZSaZ8yT1Bno+S1d8gvFol+SRXsBR32eYz5lNLx32Uvg7h0ljL96vEPS/y5WUX/z IksmvmI8muxPQzK+cW5ng== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddukedgvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Nov 2023 19:24:14 -0500 (EST) Message-ID: <7089f7f2-3000-75fe-768a-dd12d979d81c@gutov.dev> Date: Wed, 8 Nov 2023 02:24:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) 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.2 (---) On 07/11/2023 23:28, Spencer Baugh wrote: > - project-mode-line will call this on mode-line update Hopefully this will never result in writes to disk made more often than once per user command, or buffer switch, etc. > - (write-region nil nil filename nil 'silent)))) > + ;; If project-list-file is locked by some other Emacs, fail to > + ;; write rather than prompting the user. > + (ignore-error file-locked > + (cl-letf (((symbol-function 'ask-user-about-lock) > + (lambda (file opponent) > + (signal 'file-locked (list file opponent))))) > + (write-region nil nil filename nil 'silent)))))) I wonder if all cl-letf uses like this will survive native compilation, for example. Or will break over time due to internal changes in the function. Anyway, maybe an implementation like this (totally untested)? Or the warning could be skipped entirely. diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index a6426c08840..e544dfefa73 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1719,7 +1719,9 @@ project--write-project-list (expand-file-name name))))) project--list) (current-buffer))) - (write-region nil nil filename nil 'silent)))) + (let ((noninteractive t)) + (with-demoted-errors "Failed to save file list: %S" + (write-region nil nil filename nil 'silent)))))) ;;;###autoload (defun project-remember-project (pr &optional no-write) From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 07:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.16994296601276 (code B ref 66993); Wed, 08 Nov 2023 07:48:02 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 07:47:40 +0000 Received: from localhost ([127.0.0.1]:43941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0dHn-0000KW-Sh for submit@debbugs.gnu.org; Wed, 08 Nov 2023 02:47:40 -0500 Received: from mout.gmx.net ([212.227.15.15]:50589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0dHm-0000KE-9L for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 02:47:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1699429609; x=1700034409; i=michael.albinus@gmx.de; bh=49z9ozvtvnp663epdxq3NjHSeqyYnQyXRAq3MabcxUk=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References: Date; b=VXODhQHwAsj0UB0c77yNV0H6thgAYVfVYEMNZgn+PJLsLARS16fv46NP23ibMtiB 9ULv5Y3SuFAbKNuPu2y0q19U8Y7XDm86B5jGYN+/DE260pJ8KhiaPr8KhUQ5+VDXb LlylRHJU2KV0q62PciW3AFM6yCip1Z74yOaur31dh4vnBn6e5AgQHTN8XN6oQvXCB 6T6f8Zzey4js08TjO2PVvN2Ys/WS0TMYkmxbXu96Mo79Sk6Qjc+3Ksx7VuB75C44n wDpwUW+G35QBurS+Vp+48LKwYFWG/ALD4kp2LcodmA0sLhog5vjpCvDpqfBLNn95R Ya9BF0j7eFnX8KzCpA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from gandalf.gmx.de ([185.89.39.30]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mlw7V-1rhuVH49lz-00j3Lr; Wed, 08 Nov 2023 08:46:49 +0100 From: Michael Albinus In-Reply-To: (Spencer Baugh's message of "Tue, 07 Nov 2023 16:28:04 -0500") References: Date: Wed, 08 Nov 2023 08:46:48 +0100 Message-ID: <87h6lwelg7.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:VNqE2rqE7ZQE7YqfkAN+IdyrqHNRQsfZWZ267A9CZ3NyQ8H8YKg 90TFu0XkFzqjd2sTbIpfFkI3P5+2OY7eVQTdhbvnwI6bemvk2T4GqVERoQ2ofOwDQuK24hV TAmJrs9nPHXRG8TJyE33LzjW9EF6jP+uVw1UgXEi5awGpD9fIrrUKG8w0kSW4vWbjNf9nn8 HQK+dyPyGuWkvPctjkepw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:P7U/knCZySg=;aGIPHprF6muepPriTeBRj8pTb5Q NyOZ9WD+i+V9ID9MgXFMs7GQaFxMqug7xMXre5XR8FNMhnpRjgYFVD1rueSD+DFoPl4+x4FSt JVYolLTrvNVzF3nby3B/vfDxeDFGPc5lx3PvAcnE5vGG8nTh2ENUlEzrGWYmY54Po3QD7O2CO ENffdDv6EJZ34en34FkD44pirDtMsXtDA6qYMzGBZpRV5Vuxwm2MNVxkRnp6u0pWRLht88/Oa Kp6sJV49vWWs4cXaQHxYXGNyI85G5tcu+z8AhV75Ve9RE8R8Ysq/28/z541UhySpzTg3RrJH9 Cd6SN6hfTUakqUI8qTVqDuODopss9YbvRj2IsCniUAS/6lghCyvzKmupW+J4eGX2u91Elr18I TrXam2WCW2z8xNW/1LNoPC2rNTs5ksz9OAOFpiAlXidiPaf0TF7I8E9CUN4q/aTanr3Wih7f0 2WF/KvfYmIGvvtadEofgzw0WAa+p9oMQSqgdPmtGQcJAFoKnSPpnTi0CWoKhN532devB86Qjw caCy5C4rbKaXDofg9kbTLIB2CO/wkFi3p1lhg34Kwy+ezNSWB6eYKgPtLKO4NSUV3FRqt3v5h mJviut/wMKfJCk4OKEwbzn9RgHCr+Gh64vJsvdFyLqJRFJY40Hdo/RGrDM8QqT28YJ9Ns6j4p PgSBig5ZgnxTMzKampXpfhD2xGdE0/hgx+PiAOem/WLWlUp3dzSPCbZMYH8W+FoxW+fR+GQ0h HvPZygVHUyXZxFdgw5arpUr5VGrfHi737BX39ScfSGxKGEPZ4yYW2UKIwpmgfEayIlTHrzwHg shDMqrQ7fB9GLtFxOmRPuFI9L4y4syiGHPdgm+slRH0M4lUhZrl47M26TMDSq6wBUmk9hs6BW 434xAu9xA060bJmYfI1MVzJOvfr7OjKMPlqegv/sQ8oKJ15umEMp0J2IJEHY9EJahlrJBNp7j BpILF/6b5hKK3jqZjUipNstWM9Q= 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 (-) Spencer Baugh writes: Hi Spencer, > If a user has multiple Emacs instances open using one or more of these > features, it's fairly easy for both of the Emacs instances to see a > new project at the same time. In that case, they'll both call > project--write-project-list at the same time, which will clash and run > ask-user-about-lock. This will happen frequently if the user is often > looking at new projects. > > There's no correct answer the user can give to ask-user-about-lock: > either way, one of the Emacs instances will have its project-list-file > update lost. So let's not even bother prompting the user: just do > nothing if project-list-file is currently locked. If you don't care about locking project-list-file, let-bind create-lockfiles to nil while writing project-list-file. Best regards, Michael. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 12:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh , Dmitry Gutov Cc: 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.16994462148197 (code B ref 66993); Wed, 08 Nov 2023 12:24:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 12:23:34 +0000 Received: from localhost ([127.0.0.1]:44144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0hao-000289-8b for submit@debbugs.gnu.org; Wed, 08 Nov 2023 07:23:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57150) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0haj-00027q-4Z for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 07:23:32 -0500 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 1r0hZz-0004Z3-Lq; Wed, 08 Nov 2023 07:22:44 -0500 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=iEjYf7/W+WOv9/lPT8FoprgHXrFRXJ7+qXXUvBWMt+8=; b=IBcUZjEpY5d5 jFAWaNsBV9/by8GDdJwmc5Q5l5Jr931GjOnQnS1Dk4PfDgB1h1XzgcWO2HU9TbguugW6kdMp9EOT3 tup5PJWMQkmKX2lw3brUV4E2BsxzETLr43vkCf/6zGvMnYptWKkWJPLLqCGlNUuU55ZyB6KwggamL O4ICz/GvNtzoBlDYPxpQyyvicQK4vaThQdwpzDzd2D11kZK3k8u2hxRHDYYiKsYPbxQEKLnAHoNm3 5VrRofAEedGADkADAWiTV24P552vGgyaHgNQ43UtDSItYuiIeYY8vGenNaVfGug8suK0addeuu7SO bHyxSroznM+SIN0Mw7ZaXg==; Date: Wed, 08 Nov 2023 14:22:31 +0200 Message-Id: <83sf5g1lko.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Tue, 07 Nov 2023 16:28:04 -0500) References: 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: Tue, 07 Nov 2023 16:28:04 -0500 > > There are several features which will cause Emacs to frequently call > project-current, and therefore call project-remember-project, and > therefore sometimes call project--write-project-list whenever a new > project is seen. Why does project-current immediately writes the list to the file? Why cannot it keep the information in memory and write it only when the session ends, or at some random rare opportunity? > - project-uniquify-dirname-transform will call this for each new > buffer > > - project-mode-line will call this on mode-line update > > - My own private project-watch will call this based on file-notify > events. Ouch! this doesn't sound like a clean implementation to me. Writing something to a file from mode-line update? or when a new buffer is created? Why cannot we come up with a cleaner implementation? > There's no correct answer the user can give to ask-user-about-lock: > either way, one of the Emacs instances will have its project-list-file > update lost. So let's not even bother prompting the user: just do > nothing if project-list-file is currently locked. Sorry, that cannot be TRT. We cannot second-guess what the user wants to do in this case, and claim we are always right. > In the long run, the update doesn't actually get lost, because the > Emacs instance will probably make the same project-list-file update > again a few seconds later due to a later call to project-current. So > this doesn't lose anything. One more reason not to write the changes upon each change. Or at least detect that the file is locked, and schedule update at a later time, or something. Ideally, we should only write the file at exit. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 12:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169944661110875 (code B ref 66993); Wed, 08 Nov 2023 12:31:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 12:30:11 +0000 Received: from localhost ([127.0.0.1]:44161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0hhC-0002o3-Ro for submit@debbugs.gnu.org; Wed, 08 Nov 2023 07:30:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0hh6-0002IF-Oe for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 07:30:09 -0500 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 1r0hgO-00061c-Nw; Wed, 08 Nov 2023 07:29:20 -0500 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=8A0A4Cv+GW5dBaGOyfUEeq9VTDzPmV1iAOxn3WAhgm4=; b=U3ScO2BvUW6A Qj+ejPEuF+D5NJFjsi4RigB/gIPgZqrqgqwYF02UyoqmjGCxih2Q1dXm6GRUfDa5iXJVaGtzXgMqf 8Cltba3ZBSdrBJ6RXPqnZAJgFfNfo35Z8031hCyl4J17icgpdcAEQqd4dYCJgkSeFVAVGHr/fcBWV doKb+WOp+xtINbbgnGTUElMQTfI0PZPuokLNmri3U5/4bm9ufY/sZaqDrp1hb/cXtCsrxEJeSWaqQ u7zhmv0FApi/SSzkz35QANrfQYUdQuIK8+QxNLuJhL267NmAPvn3NnM72TwsTux6mOr3dJ5VCNtN/ sI+XPxJ8JtZdh86uTmajjA==; Date: Wed, 08 Nov 2023 14:29:11 +0200 Message-Id: <83pm0k1l9k.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <7089f7f2-3000-75fe-768a-dd12d979d81c@gutov.dev> (message from Dmitry Gutov on Wed, 8 Nov 2023 02:24:13 +0200) References: <7089f7f2-3000-75fe-768a-dd12d979d81c@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: Wed, 8 Nov 2023 02:24:13 +0200 > From: Dmitry Gutov > > Anyway, maybe an implementation like this (totally untested)? > > Or the warning could be skipped entirely. > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index a6426c08840..e544dfefa73 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -1719,7 +1719,9 @@ project--write-project-list > (expand-file-name name))))) > project--list) > (current-buffer))) > - (write-region nil nil filename nil 'silent)))) > + (let ((noninteractive t)) > + (with-demoted-errors "Failed to save file list: %S" > + (write-region nil nil filename nil 'silent)))))) Isn't the cure worse than the disease? we are in effect disregarding all errors that prevent us from saving the file. If those errors are not important, why save the list to the file at all? From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 13:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169944968824030 (code B ref 66993); Wed, 08 Nov 2023 13:22:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 13:21:28 +0000 Received: from localhost ([127.0.0.1]:44212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0iUq-0006FW-Fq for submit@debbugs.gnu.org; Wed, 08 Nov 2023 08:21:28 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:34481) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0iUo-0006FI-6Z for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 08:21:27 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7124A5C0459; Wed, 8 Nov 2023 08:20:42 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 08 Nov 2023 08:20:42 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1699449642; x=1699536042; bh=taCsCUF/21zzdir9q69DGGwNr3suY8b6leP S3iYf//0=; b=lEz4e6Kv8zspGyeGpK6kVctjPmR+WlfkJ1D9Y7bQ59rra2njwtN 1ShR8y+/r4f8bqfHuFip7zuYwIHx5HwLzg/1QwkCx5dN7wLSdiCmUrt7X37kY2HS prs0KEdUSXC8xyYsTgUwlezjDIKhQ/8A2f9Diz8CiDW9/GXUmXaw0wWEuJZiqPLv IKfMGO2UlQAB+D3iTcixDAG4NgRnts7Mvo2Mr7vwrzVjJWErZqKH09d8qqNl3J6R pavLBO5YRyW32P7WQR1/QCPNE6cXb0Oh3HhFwFYJ5uzE4YAsTsvtE+mq9Vf1EUnu hom6kkoGQm7rDwfVoH9KPJF0vrlG2xFZqvQ== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699449642; x=1699536042; bh=taCsCUF/21zzdir9q69DGGwNr3suY8b6leP S3iYf//0=; b=m9g7laFpOYileLxYJvHuUj4GpCYqTYFhJMdmR69tCPs6v5DvG/7 2WualS62njkSHFvt4auG1Nl6cwZibDHcGswdeWOJ9fgP6di/NU1IP1l+Z7i23W9e 8F9Q+5lLn8Bv9sd9+1uAet+0SYZD/stpGkz1tLeJbBtL1/1cw+OyVjMbl8XWz9DZ i+CPrtYWoRGwCCl74X1jsOBX8511xPyQRcoCgnMtO1a8fkgrH3N7ubUiU8yv6sak TIbciHN512MmpI1a/WMdE41aW4lCk/vkJUTmWeBGQAWrUEGmHI2b98qJYeU9dzpx tKz71X68DZMVtB/DCl873DbCfGiSLdAvLhg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudduledghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Nov 2023 08:20:41 -0500 (EST) Message-ID: <9cd0def6-67de-5e0e-9ab3-a917c34a238b@gutov.dev> Date: Wed, 8 Nov 2023 15:20:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <7089f7f2-3000-75fe-768a-dd12d979d81c@gutov.dev> <83pm0k1l9k.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83pm0k1l9k.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) 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.2 (---) On 08/11/2023 14:29, Eli Zaretskii wrote: >> Date: Wed, 8 Nov 2023 02:24:13 +0200 >> From: Dmitry Gutov >> >> Anyway, maybe an implementation like this (totally untested)? >> >> Or the warning could be skipped entirely. >> >> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el >> index a6426c08840..e544dfefa73 100644 >> --- a/lisp/progmodes/project.el >> +++ b/lisp/progmodes/project.el >> @@ -1719,7 +1719,9 @@ project--write-project-list >> (expand-file-name name))))) >> project--list) >> (current-buffer))) >> - (write-region nil nil filename nil 'silent)))) >> + (let ((noninteractive t)) >> + (with-demoted-errors "Failed to save file list: %S" >> + (write-region nil nil filename nil 'silent)))))) > Isn't the cure worse than the disease? we are in effect disregarding > all errors that prevent us from saving the file. If ask-user-about-lock signaled a specific error rather than just (error ...), we could catch only that one. > If those errors are > not important, why save the list to the file at all? It's not hugely important that the list is up-to-date at all times. I haven't encountered the conflicts myself, though. Maybe some other solution could be preferable. Michael's suggestion sounds pretty efficient, for example. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 13:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii , Spencer Baugh Cc: 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169945002224600 (code B ref 66993); Wed, 08 Nov 2023 13:28:02 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 13:27:02 +0000 Received: from localhost ([127.0.0.1]:44218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0iaE-0006Oh-9L for submit@debbugs.gnu.org; Wed, 08 Nov 2023 08:27:02 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:50967) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0ia9-0006OB-Cp for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 08:27:00 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AD02F5C050A; Wed, 8 Nov 2023 08:26:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 08 Nov 2023 08:26:13 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1699449973; x=1699536373; bh=FZVWkJn8tQxQN3V+OU6Z9lP2zQiDZrgq7Cg UpodnvWk=; b=iOrpSC/6oTLIZX8mDtQJUWvmxcRAHshEazpuKVCTrQ22waWoGUk Mv32IfHWpZ9yw4TwZY5eBquKgrGJVRme+cNO4Y7iNqwjhlj1PoEHGOA8BfqS+1M7 2rqWtQzvpfjESvAhotqT7CTbvtruLVNWOFhsRijx0H4xVN7F9IhZOro3I/YD9w4x iSJcJoiMMi+E9YUkLx4/YVcxnQX/0oLlsYYc7CAy7F9w5VA7ucz8qQLUS3KD+e7O ij963PvVvrW3gP4FDt4GceQufXYPfp7sNuiXgk9g/nPBJsMAkIrTxqrt7BUeNPud D9kw7LbhAqgqrxh7WksLam2uXMX/DZ1X+Ig== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699449973; x=1699536373; bh=FZVWkJn8tQxQN3V+OU6Z9lP2zQiDZrgq7Cg UpodnvWk=; b=NyfEQICpfqAVseIvtEb3zUd//WPF3/i/yMhnVx53skqrLGWi7Ou e56QBZ+6xL44V0Mdu6koA3VEkFeT9UTWS57TjX6KFM05pA9xPcR6CGO8JH/YcXtV mhb1bYFa4Tl+qEC4l2RyzERcJj6fnARVaBOHYwGYPFMrEh7BceAURmbtGPO2Ppny 3JW8G4GfDPaGr1XeK/EGu9PYSFNXpWWnHU6U/k7Tq8Zk4XRXXQMGpVluS4RnNlEe bJ16heHC/u5rIGGObqm95rUQh9bbjWydeytL8xrCJKmER7//qzhYf8lpA/QzBlxV 9mBPRQ2QGC5RyAVVa/QDHkfMIX3Z550xXFg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudduledghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Nov 2023 08:26:12 -0500 (EST) Message-ID: <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> Date: Wed, 8 Nov 2023 15:26:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <83sf5g1lko.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83sf5g1lko.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) 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.2 (---) On 08/11/2023 14:22, Eli Zaretskii wrote: >> From: Spencer Baugh >> Date: Tue, 07 Nov 2023 16:28:04 -0500 >> >> There are several features which will cause Emacs to frequently call >> project-current, and therefore call project-remember-project, and >> therefore sometimes call project--write-project-list whenever a new >> project is seen. > Why does project-current immediately writes the list to the file? Why > cannot it keep the information in memory and write it only when the > session ends, or at some random rare opportunity? It could indeed be written from kill-emacs-hook, or just the next time an opportunity presents. With the latter approach, though, it would be handier if the lock-prompter signaled a specific error we could catch to reschedule saving. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 13:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169945149327218 (code B ref 66993); Wed, 08 Nov 2023 13:52:02 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 13:51:33 +0000 Received: from localhost ([127.0.0.1]:44230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0ixw-00074w-P1 for submit@debbugs.gnu.org; Wed, 08 Nov 2023 08:51:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0ixs-00074e-O4 for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 08:51:31 -0500 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 1r0ixA-0005Fp-2Q; Wed, 08 Nov 2023 08:50:44 -0500 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=z64JTs3mtn69t8ypJPaN89B/2y7yLzekxiiJ5chmI8U=; b=paG7DRBRF01Z L6h0Akk7ZeUw0+9q4RM4sFjr0sT1RDdiSTC6ScBsuiUwOKOqyDE/LMzDfR8xULqyikiXPZEfiQuPR LEcf+CdhZP4OyXmAYaNfkjyj8lIcrxXPL3o1Qutvc5IFokBio7459PVH9NioBi7xLUlFPcpr5ydIc /ecRmWS2pyVe8B2Xswi5/51pdptlrt6vsrLTNNEm/TjDJt0jRH174SmClVX/H5B10GH1XOj2qO3Ra +NvVnjn9oeBr60PpBFLJ4KMc4mOeAzBkEE5tZFB5dWpKCI7jmeAWVK2J8YhAUWuDQwIjtRSty7MH/ qjrfcwBx2oIIVl1ycMH2qg==; Date: Wed, 08 Nov 2023 15:50:34 +0200 Message-Id: <83jzqs1hhx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> (message from Dmitry Gutov on Wed, 8 Nov 2023 15:26:11 +0200) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@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: Wed, 8 Nov 2023 15:26:11 +0200 > Cc: 66993@debbugs.gnu.org > From: Dmitry Gutov > > On 08/11/2023 14:22, Eli Zaretskii wrote: > >> From: Spencer Baugh > >> Date: Tue, 07 Nov 2023 16:28:04 -0500 > >> > >> There are several features which will cause Emacs to frequently call > >> project-current, and therefore call project-remember-project, and > >> therefore sometimes call project--write-project-list whenever a new > >> project is seen. > > Why does project-current immediately writes the list to the file? Why > > cannot it keep the information in memory and write it only when the > > session ends, or at some random rare opportunity? > > It could indeed be written from kill-emacs-hook, or just the next time > an opportunity presents. > > With the latter approach, though, it would be handier if the > lock-prompter signaled a specific error we could catch to reschedule saving. Why do you need an error when you can use file-locked-p to check up front that the file is locked? From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 13:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169945182127677 (code B ref 66993); Wed, 08 Nov 2023 13:57:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 13:57:01 +0000 Received: from localhost ([127.0.0.1]:44235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0j3E-0007CL-IM for submit@debbugs.gnu.org; Wed, 08 Nov 2023 08:57:00 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:59281) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0j3B-0007C7-WF for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 08:56:59 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3AB8A5C04DC; Wed, 8 Nov 2023 08:56:14 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 08 Nov 2023 08:56:14 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1699451774; x=1699538174; bh=VW8FFuCo0JHW36s73LZlDh5PFPpsDhoquiV TQk+EcXk=; b=pIEzoFLt7IoiGspgWR+3ujSfog+YvqHoXhxgp7v8Suqgaj+Z3BI Lf6mUy3OIDll3KU0tc8XJdMb7nChHUlQFyEwI5AOB3DOPw7w1pI1aXIyk7UDQ38/ VQ7J46FWqir/cm7V2C92RX+ZrDOP83vRU9Y4lcAuomp3vOpTRrgRn9ZyCkLkK5lk gBmV/khdsOyECropWydNSikwVcbrf6Tot8umKco6PiPrNJg3F6FQDGJcVjsRYmvO WJaEhbenrApXScIsvtGJdEAlLN53mYyo+3N/E2qGmNc12kiiy5J4OU8Iyz24d87t YjYx24POuDkMA0RkQPJxujqgPiHUDNIRQRw== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699451774; x=1699538174; bh=VW8FFuCo0JHW36s73LZlDh5PFPpsDhoquiV TQk+EcXk=; b=U52Nf3V3Dw6EPAEc5lmPQl8PEgjkIHTlXSzWNWA4d5DJQy5Iqeu gkvRXDZs0CcdVldxu2GTGNvjinZ9owmfWEJ8PN416PPmzMut6WAE3ep5FMfFVgP9 SW9SrGUQafHD8wOmiPS9hIu/bix532RzsF8AFnxLSGJSn2izEgKp87oKQCD23d8G AkWBppthTrtilgzF9DHuAPlOyAJ3O3rEwWoH1jHR/3kE5xXQ0Hf4sHivL4NKqpRu VSPGXuXIIp317bsfsIx8d13Mlnq5rhjwRNzeLeHMAxaJ7GTeTp7aq98/wZfDU60O qbldvfhimQjsOtygOGi+f3Mn66nk1HBzrfQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudduledgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Nov 2023 08:56:13 -0500 (EST) Message-ID: <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> Date: Wed, 8 Nov 2023 15:56:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83jzqs1hhx.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) 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.2 (---) On 08/11/2023 15:50, Eli Zaretskii wrote: > Why do you need an error when you can use file-locked-p to check up > front that the file is locked? IIUC the problem comes due to concurrent writes from concurrent writes from parallel Emacs instances. Simply checking whether the file is locked before writing, without trying to obtain the lock, is unlikely to be a reliable solution (another instance might lock it right after we checked). Anyway, these writes must be very fast and relatively infrequent. So I'm surprised that this has came up, personally. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 14:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh , 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169945195427907 (code B ref 66993); Wed, 08 Nov 2023 14:00:02 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 13:59:14 +0000 Received: from localhost ([127.0.0.1]:44240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0j5O-0007G3-7b for submit@debbugs.gnu.org; Wed, 08 Nov 2023 08:59:14 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:41839) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0j5L-0007Fo-PD for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 08:59:12 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 126BF5C00E1; Wed, 8 Nov 2023 08:58:28 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 08 Nov 2023 08:58:28 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1699451908; x=1699538308; bh=83SMuVvnPsRD8boJjudEiHG0t8IUAmHApU3 8X30VmZM=; b=U41wmWu1pLhAtrWEPt9TZ9Pfqb5QtPX+DcONVuy+FUvK13o4vm3 9xahSQorQ+7wuqumASjkHPTVXz6AQrJT1AzGISJvaxVcS8ljJHuzaQf2fE8UBRY8 478LpfeB0bt5k0PQ6FwoaN9xvlzv+PK3t/5sHwuuRucw+Uvkg9ockXVh7Kg8WioO D1QwyFHlVCvQkonyfO+Y/z3xLXkp2A70i4jzbEANprm7bxrbfbCq+WAUaH09QfHT 1RdgnaDgB5GHB0u41TvZWjWXNofy6TlAoyVyXpU5qojBC/nhY0GpSfdOLnz21pcX R8gIADS81WhUpvfcNwbA+xtTyCpLSO8ePdg== 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:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1699451908; x= 1699538308; bh=83SMuVvnPsRD8boJjudEiHG0t8IUAmHApU38X30VmZM=; b=X KtC9IBk0+aYUNr89AZpo/LUCCF7YMNQylG6FBULGaQMxkjIsqKmVMuDAVb1tllje K1mF6YJhjE+nIJ0xdpU5P5NfBrXTaRvIS9A9GjbLjCYu+/yvpB68W92fjEWclcr4 3uXBrm3WEtHYybGit0P5soXikWcX1rLaydsk77JpXAs14wsYxLB7/1hVmyUjg2x+ vXoQQddKC/ZrudsM7neXZID7JeXTMm2i+F6cntL0eSTq7o+qHAwEihX1PBRPpRo5 I40QWJsQgnmoZHemQDJYaje3wEXQk0XdYs4ItE9NhRruJUu34GVjNy3cq+JNSA3Y mn4MDU+dCePSlOKpYCJYg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudduledgheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Nov 2023 08:58:27 -0500 (EST) Message-ID: <5aec9d1b-f005-3870-f436-ecc01fc27027@gutov.dev> Date: Wed, 8 Nov 2023 15:58:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) 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.2 (---) On 07/11/2023 23:28, Spencer Baugh wrote: > - project-mode-line will call this on mode-line update > > - My own private project-watch will call this based on file-notify > events. > > If a user has multiple Emacs instances open using one or more of these > features, it's fairly easy for both of the Emacs instances to see a > new project at the same time. In that case, they'll both call > project--write-project-list at the same time, which will clash and run > ask-user-about-lock. This will happen frequently if the user is often > looking at new projects. Hmmm. What happens if we just show two buffers from different projects in the same Emacs instance? Do the mode-line refreshes trigger the changes in the list of remembered projects and subsequent writes to disk (e.g. alternating the "current" project between these two, potentially many times a second)? If so, we'll need a way to inhibit these updates, at least from the mode-line formatter. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 14:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Michael Albinus Cc: 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169945518310617 (code B ref 66993); Wed, 08 Nov 2023 14:54:02 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 14:53:03 +0000 Received: from localhost ([127.0.0.1]:44266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0jvT-0002lA-B6 for submit@debbugs.gnu.org; Wed, 08 Nov 2023 09:53:03 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:60049) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0jvR-0002kd-8o for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 09:53:02 -0500 From: Spencer Baugh In-Reply-To: <87h6lwelg7.fsf@gmx.de> (Michael Albinus's message of "Wed, 08 Nov 2023 08:46:48 +0100") References: <87h6lwelg7.fsf@gmx.de> Date: Wed, 08 Nov 2023 09:52:16 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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 (-) Michael Albinus writes: > Spencer Baugh writes: > > Hi Spencer, > >> If a user has multiple Emacs instances open using one or more of these >> features, it's fairly easy for both of the Emacs instances to see a >> new project at the same time. In that case, they'll both call >> project--write-project-list at the same time, which will clash and run >> ask-user-about-lock. This will happen frequently if the user is often >> looking at new projects. >> >> There's no correct answer the user can give to ask-user-about-lock: >> either way, one of the Emacs instances will have its project-list-file >> update lost. So let's not even bother prompting the user: just do >> nothing if project-list-file is currently locked. > > If you don't care about locking project-list-file, let-bind > create-lockfiles to nil while writing project-list-file. Hm, I think that could result in two writes clobbering each other in a way that creates an invalidly formatted file. This would happen if e.g. there were two concurrent write-regions that got interleaved like: 1. write-region(A) starts and writes first half 2. write-region(B) starts and completes 3. write-region(A) writes second half Then it would be some combination of A and B, which might not be validly formatted. From a brief look at the write-region implementation, this is possible. (The thing that would make this impossible is if write-region wrote into a tempfile and then renamed it on top of the destination. Instead write-region just writes directly into the file, opening it with O_TRUNC.) It's not very likely, but if the lock is conflicting at all and the project list is large then this will probably happen eventually. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 15:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169945603413738 (code B ref 66993); Wed, 08 Nov 2023 15:08:02 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 15:07:14 +0000 Received: from localhost ([127.0.0.1]:46118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0k9B-0003ZV-SX for submit@debbugs.gnu.org; Wed, 08 Nov 2023 10:07:14 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:37217) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0k9A-0003ZJ-9E for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 10:07:12 -0500 From: Spencer Baugh In-Reply-To: <7089f7f2-3000-75fe-768a-dd12d979d81c@gutov.dev> (Dmitry Gutov's message of "Wed, 8 Nov 2023 02:24:13 +0200") References: <7089f7f2-3000-75fe-768a-dd12d979d81c@gutov.dev> Date: Wed, 08 Nov 2023 10:06:27 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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 (-) Dmitry Gutov writes: > On 07/11/2023 23:28, Spencer Baugh wrote: >> - project-mode-line will call this on mode-line update > > Hopefully this will never result in writes to disk made more often > than once per user command, or buffer switch, etc. > >> - (write-region nil nil filename nil 'silent)))) >> + ;; If project-list-file is locked by some other Emacs, fail to >> + ;; write rather than prompting the user. >> + (ignore-error file-locked >> + (cl-letf (((symbol-function 'ask-user-about-lock) >> + (lambda (file opponent) >> + (signal 'file-locked (list file opponent))))) >> + (write-region nil nil filename nil 'silent)))))) > > I wonder if all cl-letf uses like this will survive native > compilation, for example. Or will break over time due to internal > changes in the function. > > Anyway, maybe an implementation like this (totally untested)? > > Or the warning could be skipped entirely. > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index a6426c08840..e544dfefa73 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -1719,7 +1719,9 @@ project--write-project-list > (expand-file-name name))))) > project--list) > (current-buffer))) > - (write-region nil nil filename nil 'silent)))) > + (let ((noninteractive t)) > + (with-demoted-errors "Failed to save file list: %S" > + (write-region nil nil filename nil 'silent)))))) > > ;;;###autoload > (defun project-remember-project (pr &optional no-write) Good idea using noninteractive. I agree that should signal file-locked, so we can handle it. That seems like the most elegant solution. However, interestingly, this actually seems to crash Emacs! Not sure why yet. Reproduction: 1. Open ~/file and edit it without saving (so Emacs takes the lock) 2. in a separate emacs -Q, run with M-: (let ((noninteractive t)) (write-region nil nil "~/file")) 3. Notice the separate emacs -Q immediately crashes! This is really a separate bug, but since we're talking about noninteractively handling lock conflicts, we might as well solve it here - or decide if it really should be solved. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 15:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169945715415565 (code B ref 66993); Wed, 08 Nov 2023 15:26:02 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 15:25:54 +0000 Received: from localhost ([127.0.0.1]:46144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0kRF-00042z-K9 for submit@debbugs.gnu.org; Wed, 08 Nov 2023 10:25:53 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:51511) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0kRD-00042h-Je for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 10:25:52 -0500 From: Spencer Baugh In-Reply-To: <5aec9d1b-f005-3870-f436-ecc01fc27027@gutov.dev> (Dmitry Gutov's message of "Wed, 8 Nov 2023 15:58:25 +0200") References: <5aec9d1b-f005-3870-f436-ecc01fc27027@gutov.dev> Date: Wed, 08 Nov 2023 10:25:07 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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 (-) Dmitry Gutov writes: > On 07/11/2023 23:28, Spencer Baugh wrote: >> - project-mode-line will call this on mode-line update >> - My own private project-watch will call this based on file-notify >> events. >> If a user has multiple Emacs instances open using one or more of >> these >> features, it's fairly easy for both of the Emacs instances to see a >> new project at the same time. In that case, they'll both call >> project--write-project-list at the same time, which will clash and run >> ask-user-about-lock. This will happen frequently if the user is often >> looking at new projects. > > Hmmm. What happens if we just show two buffers from different projects > in the same Emacs instance? Do the mode-line refreshes trigger the > changes in the list of remembered projects and subsequent writes to > disk (e.g. alternating the "current" project between these two, > potentially many times a second)? > > If so, we'll need a way to inhibit these updates, at least from the > mode-line formatter. Oh, I spoke too soon, perhaps - when MAYBE-PROMPT=nil in project-current, we don't call project--write-project-list. So the issue won't actually happen with project-mode-line or project-uniquify-dirname-transform. It will only happen with either: - Concurrent calls to regular project commands (e.g. project-async-shell-command or project-compile) from two Emacsen, since those set MAYBE-PROMPT=t - Concurrent calls to project-remember-project/project-forget-project and similar functions. (This is what my project-watch does, since it calls project-remember-project when a new project shows up in a directory, and if I'm unlucky that will be at the same time as another Emacs instance.) I guess that makes it less of a critical issue, but it still seems to me that this is worth fixing. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 15:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169945757016265 (code B ref 66993); Wed, 08 Nov 2023 15:33:02 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 15:32:50 +0000 Received: from localhost ([127.0.0.1]:46149 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0kXx-0004EH-Jj for submit@debbugs.gnu.org; Wed, 08 Nov 2023 10:32:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0kXu-0004E2-Df for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 10:32:48 -0500 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 1r0kXC-0002K2-6b; Wed, 08 Nov 2023 10:32:02 -0500 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=fPd/xeg6BPIUsPBoamu7vHJNUT/jEGRxfq5K9Y2TYsw=; b=qyQVfk9nKnx/ CpF4zgaCiPNTAV/Ih3ZPMVKON+OcUcDjnswnyrJmmGcbTgd3TV7iG7HaYqRmANQr/ZqLW1S6jZPp8 zgDAD3P8Rroaf3esuLeDn2Bd5TOC82GO68RTEtQQ8ebroTqdZmNWGjzxCSblDT+g82oAyQQTbuXk1 mB1suivBtCcx1+6bcNQmTrmHyKBwW7VGUSGe6AX0MTtdQ1Odkc32cnj+vgrKlIMZ0QMIEET1SC9i6 NQu5VMIwX7OPIGmZdX4nmmjXtPICP7SvHG4L53vGL55q7mSamotqzTiAD5GKDefzdceqVB5wpAlXP snyxvU8vey/Cp7INvO421A==; Date: Wed, 08 Nov 2023 17:31:52 +0200 Message-Id: <83il6c1ct3.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> (message from Dmitry Gutov on Wed, 8 Nov 2023 15:56:11 +0200) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@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: Wed, 8 Nov 2023 15:56:11 +0200 > Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org > From: Dmitry Gutov > > On 08/11/2023 15:50, Eli Zaretskii wrote: > > Why do you need an error when you can use file-locked-p to check up > > front that the file is locked? > > IIUC the problem comes due to concurrent writes from concurrent writes > from parallel Emacs instances. > > Simply checking whether the file is locked before writing, without > trying to obtain the lock, is unlikely to be a reliable solution > (another instance might lock it right after we checked). > > Anyway, these writes must be very fast and relatively infrequent. So I'm > surprised that this has came up, personally. If that's the case, just catch the error and retry, several times, perhaps with variable delays. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 15:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: Eli Zaretskii , 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169945781816647 (code B ref 66993); Wed, 08 Nov 2023 15:37:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 15:36:58 +0000 Received: from localhost ([127.0.0.1]:46157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0kby-0004KQ-HI for submit@debbugs.gnu.org; Wed, 08 Nov 2023 10:36:58 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:56307) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0kbw-0004KE-7E for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 10:36:56 -0500 From: Spencer Baugh In-Reply-To: <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> (Dmitry Gutov's message of "Wed, 8 Nov 2023 15:26:11 +0200") References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> Date: Wed, 08 Nov 2023 10:36:12 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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 (-) Dmitry Gutov writes: > On 08/11/2023 14:22, Eli Zaretskii wrote: >>> From: Spencer Baugh >>> Date: Tue, 07 Nov 2023 16:28:04 -0500 >>> >>> There are several features which will cause Emacs to frequently call >>> project-current, and therefore call project-remember-project, and >>> therefore sometimes call project--write-project-list whenever a new >>> project is seen. >> Why does project-current immediately writes the list to the file? Why >> cannot it keep the information in memory and write it only when the >> session ends, or at some random rare opportunity? > > It could indeed be written from kill-emacs-hook, or just the next time > an opportunity presents. I like the idea of writing the file from kill-emacs-hook. That seems cleaner than writing the file at random times. Alternatively, I suppose if we had a periodic timer that writes the file, that timer could also do the somewhat useful maintenance work of calling project-forget-zombie-projects. Or maybe we could just call that from kill-emacs-hook too? Just a thought. Separately: Currently, even without any locking issues, if there are multiple Emacsen then project-list-file just contains the project--list of the last one to write. So they're constantly clobbering each others' added and removed projects. If we do the writes more rarely, then we could try to read project-list-file first and add or remove the projects that were added or removed during the life of this Emacs instance, instead of just blindly writing out project--list. Then if there are multiple Emacsen around, their changes to project--list won't clobber each other, they'll just be cleanly merged. Does that sound reasonable? Either way, I can implement this. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 15:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: Dmitry Gutov , 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169945812617166 (code B ref 66993); Wed, 08 Nov 2023 15:43:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 15:42:06 +0000 Received: from localhost ([127.0.0.1]:46168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0kgu-0004Sk-Em for submit@debbugs.gnu.org; Wed, 08 Nov 2023 10:42:06 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:34093) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0kgp-0004SE-NH for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 10:42:03 -0500 From: Spencer Baugh In-Reply-To: <83il6c1ct3.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 Nov 2023 17:31:52 +0200") References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> <83il6c1ct3.fsf@gnu.org> Date: Wed, 08 Nov 2023 10:41:15 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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: >> Date: Wed, 8 Nov 2023 15:56:11 +0200 >> Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 08/11/2023 15:50, Eli Zaretskii wrote: >> > Why do you need an error when you can use file-locked-p to check up >> > front that the file is locked? >> >> IIUC the problem comes due to concurrent writes from concurrent writes >> from parallel Emacs instances. >> >> Simply checking whether the file is locked before writing, without >> trying to obtain the lock, is unlikely to be a reliable solution >> (another instance might lock it right after we checked). >> >> Anyway, these writes must be very fast and relatively infrequent. So I'm >> surprised that this has came up, personally. > > If that's the case, just catch the error and retry, several times, > perhaps with variable delays. Perhaps, but it would be nice to do that by catching specifically file-locked rather than catching all errors. Which is something which can't be done right now, other than with the cl-flet approach in my original approach. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 15:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169945833317512 (code B ref 66993); Wed, 08 Nov 2023 15:46:02 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 15:45:33 +0000 Received: from localhost ([127.0.0.1]:46175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0kkG-0004YO-SW for submit@debbugs.gnu.org; Wed, 08 Nov 2023 10:45:33 -0500 Received: from mout.gmx.net ([212.227.15.19]:53447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0kkD-0004Y7-TH for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 10:45:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1699458283; x=1700063083; i=michael.albinus@gmx.de; bh=g0GMK2rkrU4P+hTKX2Fbu6Q2oJ+Lg37FFw5r+i3Dluc=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References: Date; b=e50Tvvt4pzzH45DwBIKLbhh9+Wh/rcVR+o7gv3tVHm4XynrV5PsByKXTresueHRV 2ryy9fMPBaU8B1xRLogs5mWGC2i+1FW5zrzfF5byGjJso2ScHxkKXBcJEfh8YWnm1 I0d0yKVPRqg8VX2oRA7VhYlQ/RCfSinmqUZblJSRO52t32L0bzz2TIHeby+4Vvwqa ZGOSmF3GK9MLyObxgr2MTu43chN3t3T4s4uugTpaI5QTDeiaQIBwjJ9KW8tGm9twQ WDqD05VXECiUveVUca4Ry6K9i3I3CsoKOPzeF2Gx6+eHVQHtsGFyhHUEMpk7dH7Yp HWkjbbIBXWsJSEraeQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from gandalf.gmx.de ([185.89.39.30]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MmlT2-1rj7pF2dCo-00js2Q; Wed, 08 Nov 2023 16:44:43 +0100 From: Michael Albinus In-Reply-To: (Spencer Baugh's message of "Wed, 08 Nov 2023 09:52:16 -0500") References: <87h6lwelg7.fsf@gmx.de> Date: Wed, 08 Nov 2023 16:44:43 +0100 Message-ID: <87zfzockr8.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:5+qKIagjXr9btV+WMlllxhjqMqMssqMagwy24t4Lt9ZUOzWYV0S 8CL4TWqwEzJPV7iebCOoINVRZQwVs9EPT/nS2Q4b6y8qVQzmn+ZRSKrxFHIgzKdLQDRTolm s9ceiDFNmxnI/RogrcMjkL0mulZnLTZEEYHW9d2WbsEEqV7Jycw6jPYbSWdW2EcESqWtQMy UqtjhumB11licvsX5Rf4Q== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:nJKD3VzgzPg=;iMSvA+M6aRL28ctSN1Ab0Oj86Lk BFnvO7TU3NIy1nuKhhvrNXMRBh/gpj/deBgp+1Xt4AMiHJpygL4AQI9WoXgITAJMn7OwJsL8t xOeBIaVbS8iuDYkihScWwa2lhuoxRRqqUBiRy+msmbMa/jK4M3D8S1sxPNDxbbh5aG0AarUpl EaJw/b7HBZpeWhOSVzbSz4JiGaws8dWZ+RM97UoL7ItSbkki2zKfAKT6nBX/Al6aRkuAvBYdn N+Z3/7W4Qj9hZQIvrTRWEGKXbXuiUbS8/3wh5LC9ltJfTAcuLRZJUhRbhtvvAw4inv6YBYIqJ 1GbKIonckuSdnAZMsmFhH1s4VZrFfhBHrsft+fJQt5hdonBk2SO6qnqIOJ8ApjsL8XVhOKGn6 6njATsKXPpbcRoiqiRN9YfG8xBBmmdl5M8tMMCAF/HAJrTB/KISvSPwiLOOEOBW4H7uaaygr/ d2M2pdCyeLNqhH+CfrNac6qy9rZH8ySEpi6l29J1rEhm6DazKy2sv+RDX3ulECeuBPtvzQCqx 1Swt/vTSRztwpUNdIlkdI2l/6U2/dHH5A/tMR4IyN5q/eFYii3P92hk0hQgDZtguBnxs1jXZv kyJX3KGLSLmkDIHy2AM9eoC7DJyCL0JpiH/dQwoRKieWhPDQSJ14wwDH6MB60eE6UFLeZ0RUz BvPir3hAgy24WbdmhCaHPsoNdulAzPR1hcWNvG79G9ss429wEjmFgo7SaRuoe9dBNEU9IukOx ZsJZTh4qC+GKUzo48JA4O0wsxfj/QKrkZunC30BHvVLBoV+D8jwynX6J+dcicg9WQAO2ngy16 Kmw4nf2u6fgYXA1P7PyKKDsB6Ka0hll+GmeotxRVK27rwMkmytQJRKwTafqDJwAdJwQ0U1pu8 utfo56Ss5HRvcP9rDjrEVzoO+/1mjylBtGGEUWRL7x1T6gwEGmbJAgLEdUzl/L3kH3f5lUYOY ZHZJu3YoNzt4Ax/l7Nsn1n6BGco= 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 (-) Spencer Baugh writes: Hi Spencer, >> If you don't care about locking project-list-file, let-bind >> create-lockfiles to nil while writing project-list-file. > > Hm, I think that could result in two writes clobbering each other in a > way that creates an invalidly formatted file. Alternatively, you could check the status via file-locked-p prior calling write-region. I don't use project.el, so I don't know what's the best. Overwriting ask-user-about-lock seems to be a bad choice, IMHO. Best regards, Michael. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 16:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169946121422658 (code B ref 66993); Wed, 08 Nov 2023 16:34:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 16:33:34 +0000 Received: from localhost ([127.0.0.1]:46206 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0lUk-0005tN-7u for submit@debbugs.gnu.org; Wed, 08 Nov 2023 11:33:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0lUg-0005t8-8W for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 11:33:33 -0500 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 1r0lTx-0005fD-TV; Wed, 08 Nov 2023 11:32:45 -0500 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=Po/PAf+0GGPzKhMjCha8yjXMo7VYIhuJi5NALbUA6S0=; b=kA+lj5n6qjyx jYkq6XTdFq/lhoDHpp3N7Yigcsco/0ZCcPbUW3duEt0L9K1ZHG0eAKIWm+Rrkjd4WNuRko7W4P4jy qVD6DslqwgsOCxi6UidGFTGHdf9OMeFYxbs6bfA7hNJ3PJtOV9vEOi7sgIsDlBrg7swzf7DYEDeF3 sjUqpekQhv+LKdb6grc8fGlJnaV2NEll1x4zCFSErcXdycr6dOq0ZVcNUM1KVXby4OWLV7Nnb+HHZ kuVQuJB8WjJWU6BcsmIEMLiAosuKKy4WW6p5z4g8gpbEZ/5MP5LrIseSuXUwgG3NOYW5dRiPy0goI Sl5CWDAbLYMSamWA3DxPFg==; Date: Wed, 08 Nov 2023 18:32:35 +0200 Message-Id: <83h6lw19zw.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 08 Nov 2023 10:36:12 -0500) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@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 (---) > From: Spencer Baugh > Cc: Eli Zaretskii , 66993@debbugs.gnu.org > Date: Wed, 08 Nov 2023 10:36:12 -0500 > > Alternatively, I suppose if we had a periodic timer that writes the > file, that timer could also do the somewhat useful maintenance work of > calling project-forget-zombie-projects. Or maybe we could just call > that from kill-emacs-hook too? Just a thought. There's midnight.el for that kind of jobs. > Separately: Currently, even without any locking issues, if there are > multiple Emacsen then project-list-file just contains the project--list > of the last one to write. So they're constantly clobbering each others' > added and removed projects. If we do the writes more rarely, then we > could try to read project-list-file first and add or remove the projects > that were added or removed during the life of this Emacs instance, > instead of just blindly writing out project--list. Then if there are > multiple Emacsen around, their changes to project--list won't clobber > each other, they'll just be cleanly merged. Does that sound reasonable? I thought these writes were already just adding projects, not clobbering the list. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 16:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169946136422931 (code B ref 66993); Wed, 08 Nov 2023 16:37:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 16:36:04 +0000 Received: from localhost ([127.0.0.1]:46211 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0lX9-0005xm-PJ for submit@debbugs.gnu.org; Wed, 08 Nov 2023 11:36:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51116) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0lX8-0005xJ-29 for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 11:36:02 -0500 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 1r0lWQ-00060h-4a; Wed, 08 Nov 2023 11:35:18 -0500 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=yC4nEI/t+Xban6VCzm1/bBxcoou2hr2rqub9WVLcVWQ=; b=Cn/ocviA1KLb k/a8bjW3cFFGRiW6Pw1Q39+3fa/vuYkA14pZcJAHaljmZavjX0z8Wjqp7667DS4cJTGlU5I7dqW5k 9x2evmMsttmGel+W5UToljsliwdeEM/4EqBccVoBya3qWwvU5bd5cdW4nodmuyMZphaxyPV1pYM4k hXGtGnyQvTHKxDxo4WxoAi3/zY9SgUf8c4JUjxpUitk+WWiRG4DDrqZZm9kn/GeqeYiNxh7mLPDyt clJmF0mkTrqjFioCtlqcZBsudlq6bvQtf9fWUBwQCryGBdOktdsJ6gt1urfbqgjG1n+Gb0YtORZpK rL97vLYTeKlbVyn362ST/w==; Date: Wed, 08 Nov 2023 18:35:08 +0200 Message-Id: <83fs1g19vn.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 08 Nov 2023 10:41:15 -0500) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> <83il6c1ct3.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: Dmitry Gutov , 66993@debbugs.gnu.org > Date: Wed, 08 Nov 2023 10:41:15 -0500 > > > If that's the case, just catch the error and retry, several times, > > perhaps with variable delays. > > Perhaps, but it would be nice to do that by catching specifically > file-locked rather than catching all errors. Not sure I follow: userlock.el signals a very specific error, doesn't it? Or what am I missing? From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 16:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Michael Albinus Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169946141322998 (code B ref 66993); Wed, 08 Nov 2023 16:37:02 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 16:36:53 +0000 Received: from localhost ([127.0.0.1]:46215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0lXx-0005ys-4T for submit@debbugs.gnu.org; Wed, 08 Nov 2023 11:36:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0lXv-0005yf-Fo for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 11:36:52 -0500 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 1r0lXD-00069O-8v; Wed, 08 Nov 2023 11:36:07 -0500 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=mkP0GLepaG6Ebk5NvDh1Yfb9P4KEM2164qVebaDvxZs=; b=lnFVJGcJ2qJu dVylGznTbVd7HPN7G9OElRNTsdx/AvVkMvPvS/6ltqNdA05zTDM4sdzFJKTUeAAwbv125mLT4gyB6 ElQ5iOp19vIL0m08yTv4ecvoeLFI7dKcU1tlKKUHKwJDgzUZNKMzJ1cxXKXcX9X6FQxGoChdVup6u c9fIZ4EYYWgsByyOIeGrs6NwYii6eAfQSYVQWnEcubteh1PyJwVudNOKnmWvY8qmdzWXCILiJLg5O ya2JxxkazNDKQNLWqCo3bmqil/JijJBaZamwlPkKfbQ7p05bZnQ/TnhDCoLt+NVXEUXBLUNtgN704 lPtZE0SBiqr3Onu9KJ3bvA==; Date: Wed, 08 Nov 2023 18:35:58 +0200 Message-Id: <83edh019u9.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87zfzockr8.fsf@gmx.de> (message from Michael Albinus on Wed, 08 Nov 2023 16:44:43 +0100) References: <87h6lwelg7.fsf@gmx.de> <87zfzockr8.fsf@gmx.de> 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 (---) > Cc: 66993@debbugs.gnu.org > From: Michael Albinus > Date: Wed, 08 Nov 2023 16:44:43 +0100 > > Overwriting ask-user-about-lock seems to be a bad choice, IMHO. Agreed. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 17:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169946318426139 (code B ref 66993); Wed, 08 Nov 2023 17:07:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 17:06:24 +0000 Received: from localhost ([127.0.0.1]:46225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0m0W-0006nW-8n for submit@debbugs.gnu.org; Wed, 08 Nov 2023 12:06:24 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:58115) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0m0U-0006nI-Gc for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 12:06:23 -0500 From: Spencer Baugh In-Reply-To: <83fs1g19vn.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 Nov 2023 18:35:08 +0200") References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> <83il6c1ct3.fsf@gnu.org> <83fs1g19vn.fsf@gnu.org> Date: Wed, 08 Nov 2023 12:05:38 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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: Dmitry Gutov , 66993@debbugs.gnu.org >> Date: Wed, 08 Nov 2023 10:41:15 -0500 >> >> > If that's the case, just catch the error and retry, several times, >> > perhaps with variable delays. >> >> Perhaps, but it would be nice to do that by catching specifically >> file-locked rather than catching all errors. > > Not sure I follow: userlock.el signals a very specific error, doesn't > it? Or what am I missing? By that you mean file-locked? It only signals file-locked if it first prompts the user, which is what we want to avoid. If noninteractive=t, then it just signals error: (if noninteractive (error "Cannot resolve lock conflict in batch mode")) Possibly we should just change that to signal file-locked too. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 17:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169946545929782 (code B ref 66993); Wed, 08 Nov 2023 17:45:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 17:44:19 +0000 Received: from localhost ([127.0.0.1]:46266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0mb9-0007kG-LV for submit@debbugs.gnu.org; Wed, 08 Nov 2023 12:44:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0mb4-0007jy-Um for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 12:44:14 -0500 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 1r0maM-000212-HI; Wed, 08 Nov 2023 12:43:26 -0500 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=9BZH0C22P3pJCKQDMcfK6JlHp8Z5K1gg9XAq5MadWh0=; b=ar3G/oVZLRq4 vFKLsDgejqvg6GsXJG6qQVI0MItVGmBcsFE8i/RwLnmBhDOkWXKGAw20zrkhUTYHv1q3gwbvwJPSY LE86o6I3Z7OWFNvhhvRO99mxVTChYaF01ODQVHKQQx15h3GKLwuCcZAoCOq01ztJCDj0agHtA+LoU WAWJxfM7QynPWt/pwa8fnwmhsQHoVRQg3TojrIGqxkOi2TE1SsmATSTs73NjwLeqShDkJtz3PTcNA zSIOlqmLnlYQxLizQ8AAzzFkezMXxEhiG6TeW77GGwDtcMzv0LrHi/Nptgf0HMz8gTyoWwcZydI96 nJUKJMTnTBGd6tgjOlwt9g==; Date: Wed, 08 Nov 2023 19:43:16 +0200 Message-Id: <83bkc416q3.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 08 Nov 2023 12:05:38 -0500) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> <83il6c1ct3.fsf@gnu.org> <83fs1g19vn.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: dmitry@gutov.dev, 66993@debbugs.gnu.org > Date: Wed, 08 Nov 2023 12:05:38 -0500 > > Eli Zaretskii writes: > > > > Not sure I follow: userlock.el signals a very specific error, doesn't > > it? Or what am I missing? > > By that you mean file-locked? It only signals file-locked if it first > prompts the user, which is what we want to avoid. If noninteractive=t, > then it just signals error: > > (if noninteractive (error "Cannot resolve lock conflict in batch mode")) And that is not specific enough? And why the noninteractive=t case is relevant here, btw? > Possibly we should just change that to signal file-locked too. Or something else. If needed. In any case, these are minor details, the main point is that this error can be caught. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 20:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169947628017560 (code B ref 66993); Wed, 08 Nov 2023 20:45:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 20:44:40 +0000 Received: from localhost ([127.0.0.1]:46355 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0pPk-0004ZA-5h for submit@debbugs.gnu.org; Wed, 08 Nov 2023 15:44:40 -0500 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:36995) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0pPh-0004Yu-79 for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 15:44:38 -0500 From: Spencer Baugh In-Reply-To: <83bkc416q3.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 Nov 2023 19:43:16 +0200") References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> <83il6c1ct3.fsf@gnu.org> <83fs1g19vn.fsf@gnu.org> <83bkc416q3.fsf@gnu.org> Date: Wed, 08 Nov 2023 15:43:53 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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 (---) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org >> Date: Wed, 08 Nov 2023 12:05:38 -0500 >> >> Eli Zaretskii writes: >> > >> > Not sure I follow: userlock.el signals a very specific error, doesn't >> > it? Or what am I missing? >> >> By that you mean file-locked? It only signals file-locked if it first >> prompts the user, which is what we want to avoid. If noninteractive=t, >> then it just signals error: >> >> (if noninteractive (error "Cannot resolve lock conflict in batch mode")) > > And that is not specific enough? Are you suggesting that we should condition-case and check the string inside the error is "Cannot resolve lock conflict in batch mode"? Otherwise, if we just catch all errors, this will also catch and suppress errors for failures to write to the file, which would be bad. > And why the noninteractive=t case is relevant here, btw? Because we don't want to prompt the user, we just want to signal an error if there's a lock conflict. >> Possibly we should just change that to signal file-locked too. > > Or something else. If needed. > > In any case, these are minor details, the main point is that this > error can be caught. Well... the other issue is that Emacs crashes if you bind noninteractive=t and then hit a lock conflict. e.g.: 1. Open ~/file and edit it without saving (so Emacs takes the lock) 2. in a separate emacs -Q, run with M-: (let ((noninteractive t)) (write-region nil nil "~/file")) 3. The emacs -Q crashes From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 21:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: Eli Zaretskii , 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169947747519998 (code B ref 66993); Wed, 08 Nov 2023 21:05:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 21:04:35 +0000 Received: from localhost ([127.0.0.1]:46384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0pj0-0005CU-K1 for submit@debbugs.gnu.org; Wed, 08 Nov 2023 16:04:34 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:49929) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0pix-0005CD-MD for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 16:04:32 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id C052D3200947; Wed, 8 Nov 2023 16:03:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 08 Nov 2023 16:03:47 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1699477426; x=1699563826; bh=RjvM8+uC/0yBJIxspxDDSCuQIioqKvbd8KP DBO9Va4Q=; b=d4IpzAZPYiDUD2HXQu2J9h65onv8MnRq7+VkeSEQFiVyj9TmWR4 9W3JoCd/XVxLfv2KT9zxtExFoxIFG9jaBOkytNjvSBAwlUipZxCedpiliiq7ZB8W VzsXpGRKGNg8QwPY9vKj80t2tMtHe5V1li6OzPQ0zUQks9hVHo870DO0sHCCEfje 5D1+lvW78G1dKQEN63QqOe7q8NygkDpTJphRXMt3HpwTs5Ud09WSLuBVVzspAwSc aq74aBULs6gRi4/AcUy6tYJVAwCnfiPZTc0DJyqZcj5RVEk9RvX8u0DQoWUDm7xz CFM4kb5PpXYDrBBT7oTBhm8vfNIlBnG7aig== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699477426; x=1699563826; bh=RjvM8+uC/0yBJIxspxDDSCuQIioqKvbd8KP DBO9Va4Q=; b=SC3f6agvyufZMZBEwjdpQJ8JyesRAXZpHPPClVHoCxb+H+LLnju nBlJVEIIZ95kCPpfRkJAPTZZ5nDXSmqqd1AD3VCANLnzToisCMDt625dUhKa/dFb NfJ7gWMe0l+CsUEazlj3K5avX2ecjqjP2YdF3R4qbhT6hKX3aO9I6/ULVwRQa2GO V3r+f1u5aH1J63rU+96w3j9jVVjmHuusujynuvnTSUg09txWRx0O6O4t06/XQGTn xflNTVj14K3nx53eYhUJsJP928XmeJ32JCyWCKzC60N1G8nU/I9+Lk33ec9BbsaS +kdjAHY+nYgoWrLISpbAYMqrt/JRE0MgXng== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudduledgudegvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhhfelieffgfevveduuefgieefueffvefguedtieethfeigfetvdehueev vddvfeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Nov 2023 16:03:44 -0500 (EST) Message-ID: Date: Wed, 8 Nov 2023 23:03:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) 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.2 (---) On 08/11/2023 17:36, Spencer Baugh wrote: > Separately: Currently, even without any locking issues, if there are > multiple Emacsen then project-list-file just contains the project--list > of the last one to write. So they're constantly clobbering each others' > added and removed projects. If we do the writes more rarely, then we > could try to read project-list-file first and add or remove the projects > that were added or removed during the life of this Emacs instance, > instead of just blindly writing out project--list. Then if there are > multiple Emacsen around, their changes to project--list won't clobber > each other, they'll just be cleanly merged. Does that sound reasonable? > > Either way, I can implement this. If you're sure that the added utility is worth the complication in the code, why not. Please post some performance measurements for before/after, though. E.g. how long project--write-project-list takes without re-reading the file, and with the new, merging approach. Though it's probably okay. BTW, that reminds me of the Fish shell's history merging between parallel sessions. I think it was automatic in some version, and now it's manual again (https://github.com/fish-shell/fish-shell/issues/825). From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 21:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii , Spencer Baugh Cc: 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169947754120118 (code B ref 66993); Wed, 08 Nov 2023 21:06:02 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 21:05:41 +0000 Received: from localhost ([127.0.0.1]:46389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0pk5-0005EQ-2p for submit@debbugs.gnu.org; Wed, 08 Nov 2023 16:05:41 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:55325) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0pk2-0005E9-HA for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 16:05:39 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id E7F763200947; Wed, 8 Nov 2023 16:04:53 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 08 Nov 2023 16:04:54 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1699477493; x=1699563893; bh=nL2Rkf5DaysZ6X10OBARasLy8YqDQus4QRE /PNHUeXA=; b=Gv6IiMNWul4GbEbg4QZKfYSmqEIDA/nOIvAneI/b1HUqwnznCjD 3RsOysixdQ+kBjUvQW59tvDkwcXz4shykaBlqtPfXKihLGSHbLwqmhyWww/zCWhp scty27Wq+swN1LS1rI2XPeJpJB5ialLCoky7J3sexjv3Vxpp+5rAvM59lrETlY7v o/TYT/8VnbHVW3FBo9xsE80j3ycr8sO+TNo5oeDu8F7QogEee+6IJVy5p3s8eQvT LF5gepawfOJ4rloUHmxGw0gm6qyKZalL2u2ioBc6VlvcjYdUYU+nUHemIuLKJy3V Sjavhn2uQI7ClbahZshN83BQLw/mzYMJjWw== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699477493; x=1699563893; bh=nL2Rkf5DaysZ6X10OBARasLy8YqDQus4QRE /PNHUeXA=; b=oLGv2u6MFl7a3j4x7WSvsJCO2BF7hUHvOuJtO5pkz0zvZt437Xf 11tl/qsHAMTnOUB6SggFnvwS/3et7NOluuM/Sj0wgOhNv0F+wT85LVx5VVLZ1RJ4 0t+x2XEhAnO9zEli2iXDPXjn0zmegJXPuRgm8TDeomIRJsb7x/yMbxnLaj64REvh FqOCyu143+s0BMQSerOTtMCpdem0d6zVkhw7XqLNlAVnx6HedTfVPyQ8yOLwHaMT mUbq8Z4+5ZWFuzWCKDSGYn+y0LDv0y+ViWEKS2c7eJW/vNwQPGDUfqoww75BAUZc JBOaRkV2NOKwJw9ElF7TZL9YqnO+ylER26g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudduledgudegvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeev ledvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Nov 2023 16:04:51 -0500 (EST) Message-ID: <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> Date: Wed, 8 Nov 2023 23:04:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83h6lw19zw.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) 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.2 (---) On 08/11/2023 18:32, Eli Zaretskii wrote: > I thought these writes were already just adding projects, not > clobbering the list. The file is re-written in full every time e.g. to remove the previous mentions of a project that should now be moved to the top. And also for simplicity. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2023 21:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169947812921030 (code B ref 66993); Wed, 08 Nov 2023 21:16:01 +0000 Received: (at 66993) by debbugs.gnu.org; 8 Nov 2023 21:15:29 +0000 Received: from localhost ([127.0.0.1]:46398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0ptY-0005T7-VT for submit@debbugs.gnu.org; Wed, 08 Nov 2023 16:15:29 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:33281) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0ptU-0005Sr-Qk for 66993@debbugs.gnu.org; Wed, 08 Nov 2023 16:15:27 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id BA47E32008FA; Wed, 8 Nov 2023 16:14:39 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 08 Nov 2023 16:14:39 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1699478078; x=1699564478; bh=s/yzTYLZsOiycd2HlzzkcYnCPrkcBgrTOy7 H64dqCuM=; b=lCC8R+ZW+wH7+lNlEOlfDdBTYqqKcHiKpkzysQttNaBxWUp0TIV U+IpG8zJ9mGRcFykbCFywOUFZOsiCbb9PYXSxEr63ergljQjZrfBdHlAgNj5Xj3D Pa1fqUNMXEZNepL+xWJrV0en+GodFL+PLB6ymV4+JU2yvdi8OTaus8prdt+Ttyxe Ug/x5jk/bcExQUFG2lqvQnxrEGZ61LczsT/loYWo35bIaqmAb7Hg79SBBGuzN3Yf 2EiXXUCzKRhO4NIkawHQbgr618ZhSoaNqL//c2yrwCuNmA+jcQlmQ/vvMsF2VvZa O1wUlruvLffWWWTuwk/BPKi031/aVDqVNEA== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699478078; x=1699564478; bh=s/yzTYLZsOiycd2HlzzkcYnCPrkcBgrTOy7 H64dqCuM=; b=TNfcBidJyBSkufKHXa1UPp7tGTyO01ucbxaGnpY9+qvQdkqOC3D QLvGhnc7sl974kv8ZoWmWQyZOvGFzoyJWYBW32e+q4WuE/s1rb0VEVyJW2bY0Gfg hXFNLWbDfN0vEdCokTC4bAFW2VT0LqnEhi+U8Ail6yLpHMHpHhfvUbZuI4Wt2Jyw ZkF+uG2Pd3GYT62HdwZg/4zQxL1tQvTucaP1A2YDOTRViKTDDufeb85YfqWElXPr C4fGa788ZSo9VAuiqRKtc2NcMFZQ0qbR1Wm0eROPq0flAAb4y6WgEu/HwrbvL/Hr ZcmysZMg0eELZgVvrNem78ICl4wSJDMjhaw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudduledgudeghecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeev ledvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Nov 2023 16:14:37 -0500 (EST) Message-ID: <4a7ef18e-f559-8835-22f4-3bb987e5e752@gutov.dev> Date: Wed, 8 Nov 2023 23:14:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <5aec9d1b-f005-3870-f436-ecc01fc27027@gutov.dev> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) 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.2 (---) On 08/11/2023 17:25, Spencer Baugh wrote: > - Concurrent calls to regular project commands > (e.g. project-async-shell-command or project-compile) from two > Emacsen, > since those set MAYBE-PROMPT=t Since they are usually triggered manually, the user will have to try hard to launch them at the same time. > - Concurrent calls to project-remember-project/project-forget-project > and similar functions. (This is what my project-watch does, since it > calls project-remember-project when a new project shows up in a > directory, and if I'm unlucky that will be at the same time as another > Emacs instance.) Note that if your code triggers the rewrites of the project-list file frequently enough so that the conflicts happen, doing more work during that time (e.g. reading, re-serializing, and then writing the file) might actually cause some disk/CPU usage increase. (Although if the conflicts happen due to synchronous firing of inotify watches in parallel Emacs instances, then probably not.) BTW, the merging algorithm to use it is not very obvious (especially if we're going to do that in kill-emacs-hook). E.g. if one instance removed a project from history and another did not, we probably want to have it removed in the "merged" version. > I guess that makes it less of a critical issue, but it still seems to me > that this is worth fixing. I'm glad to hear that the current design is working fine for the expected usage scenarios, but indeed, why not make it more resilient. If we don't sacrifice too much of something else. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2023 06:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169951163712701 (code B ref 66993); Thu, 09 Nov 2023 06:34:02 +0000 Received: (at 66993) by debbugs.gnu.org; 9 Nov 2023 06:33:57 +0000 Received: from localhost ([127.0.0.1]:46577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0yc0-0003Im-60 for submit@debbugs.gnu.org; Thu, 09 Nov 2023 01:33:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46870) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0ybv-0003IS-Hr for 66993@debbugs.gnu.org; Thu, 09 Nov 2023 01:33:55 -0500 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 1r0ybC-0004EK-Pv; Thu, 09 Nov 2023 01:33:06 -0500 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=/KdIXd4Cb4cgGLZDKoUFUol2B1XFGI1jeeLqFn/aPxU=; b=CoaYtsXxoZk9 utRzaIH1RCRq8hnq2PirZFeEX+aIPQsI94xMfvc69sPew3yeI8S8K1GT5fFlFcUbg2kojAy9pKQEv oZvLGXNg1cw9G5KseYpHjp7InrXoXFgAldRpNhDA+aGNd70so5cH8NoDhnEFtOeA1wHsk5nD/EeRV LPmSAQYnfKPPcsF09LlkopYj0tBiIPMbwTswIOBADML5MtJ/1h3q7ALy37v6FgyhePuNNtGgngLaz BJ2Ju89eOL++amjUmXYLJOEu0VsVJicByOd8xZ4oCy2YyWubBeLk4gRrezJdexKW53mRp0zM60Fqe 2CEOlDE7IQDfjooY8Xx7YA==; Date: Thu, 09 Nov 2023 08:32:58 +0200 Message-Id: <835y2b1lnp.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Wed, 08 Nov 2023 15:43:53 -0500) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> <83il6c1ct3.fsf@gnu.org> <83fs1g19vn.fsf@gnu.org> <83bkc416q3.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: dmitry@gutov.dev, 66993@debbugs.gnu.org > Date: Wed, 08 Nov 2023 15:43:53 -0500 > > Eli Zaretskii writes: > > >> (if noninteractive (error "Cannot resolve lock conflict in batch mode")) > > > > And that is not specific enough? > > Are you suggesting that we should condition-case and check the string > inside the error is "Cannot resolve lock conflict in batch mode"? That's one way, yes. Another one is to use define-error to define a new error type for this case. > > And why the noninteractive=t case is relevant here, btw? > > Because we don't want to prompt the user, we just want to signal an > error if there's a lock conflict. ??? Is project-current always used in a non-interactive context? I don't think so. When some interactive program calls it, noninteractive will be nil, and what userlock.el does in that case is not what you describe. And if you are saying that some program binds noninteractive to a non-nil value to avoid asking the file-locked question, then with the error-catching as discussed above in place, that program won't need to do that anymore, right? (Also see below for why this binding is problematic in a more general sense.) > Well... the other issue is that Emacs crashes if you bind > noninteractive=t and then hit a lock conflict. e.g.: > > 1. Open ~/file and edit it without saving (so Emacs takes the lock) > 2. in a separate emacs -Q, run with M-: > (let ((noninteractive t)) (write-region nil nil "~/file")) > 3. The emacs -Q crashes (Didn't you just say it's a separate problem?) It doesn't crash here, it exits with exit code -1. Which is a direct consequence of binding noninteractive non-nil: signaling an error in that case shows the backtrace on stderr and exits. "Kids, don't try that at home!" From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2023 06:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169951191313164 (code B ref 66993); Thu, 09 Nov 2023 06:39:02 +0000 Received: (at 66993) by debbugs.gnu.org; 9 Nov 2023 06:38:33 +0000 Received: from localhost ([127.0.0.1]:46582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0ygS-0003QG-Vs for submit@debbugs.gnu.org; Thu, 09 Nov 2023 01:38:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33138) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0ygR-0003Q3-Vu for 66993@debbugs.gnu.org; Thu, 09 Nov 2023 01:38:32 -0500 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 1r0yfj-0004oy-M1; Thu, 09 Nov 2023 01:37:47 -0500 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=qJoK+vOSMjdGxYbutkd3VlWwKzJV82EB/i9Fa0toXsY=; b=N2O9MgkRuJlm pbVkULrikw/HvZ4B9sUTAurZAz475qzAkP8TPBj46oxNyKaSeXdfSkMKlHFFMUMzOckgBL0lttkns abiZesLntp6GUE2KzlhCpb4i4syiUSXafFFlzyrJyjv8ZCrEOi9+Fa5NMMNG9+TDBIkX0cwaj1VBP pcJMGfD2HJyWA/PPL1N98XQk3uhf5lUisDfhbLTiUlhL593ailgmSGFwS/kuXDEmThwTGwkNz0F1b Rj7Feh+efxVTgK3q0M4NhK97aLS5Zc2TT0AUjZASjWDlkalcqXYMSSfJZ2HRBwEqDE+U/SSKOkJUu v2R3eDkbDr5hzQ7aa5yswA==; Date: Thu, 09 Nov 2023 08:37:39 +0200 Message-Id: <834jhv1lfw.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> (message from Dmitry Gutov on Wed, 8 Nov 2023 23:04:50 +0200) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@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: Wed, 8 Nov 2023 23:04:50 +0200 > Cc: 66993@debbugs.gnu.org > From: Dmitry Gutov > > On 08/11/2023 18:32, Eli Zaretskii wrote: > > I thought these writes were already just adding projects, not > > clobbering the list. > > The file is re-written in full every time e.g. to remove the previous > mentions of a project that should now be moved to the top. I don't understand how this resolves the concern about clobbering. If each Emacs session just writes its list of projects to the file, without refreshing the list due to additions done by another session, they will still clobber each other's lists, no? This could be avoided if the writer would read the file before rewriting it. Can you tell why the list of projects is saved on a file that is global among all sessions of the same user? Would it make sense to make the file specific to an Emacs process? From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2023 11:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169952796517808 (code B ref 66993); Thu, 09 Nov 2023 11:07:02 +0000 Received: (at 66993) by debbugs.gnu.org; 9 Nov 2023 11:06:05 +0000 Received: from localhost ([127.0.0.1]:46863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r12rK-0004cu-23 for submit@debbugs.gnu.org; Thu, 09 Nov 2023 06:06:05 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:50167) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r12rF-0004cZ-W9 for 66993@debbugs.gnu.org; Thu, 09 Nov 2023 06:06:01 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A540C5C0373; Thu, 9 Nov 2023 06:05:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 09 Nov 2023 06:05:13 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1699527913; x=1699614313; bh=KH+d9CcaXbAlOVzyyZlEDaOLIAY4o9OGKQN GXZuhZ5w=; b=OeGnnXg9GuAiSaJykNBM6a/ItVwUkkNVpjWyNbdV+F11Gb9LSDR hIFGe5BAqsUpPkzrG5ES9rY+l9l4BP6I4yjPeADf95jjPwWet6sGH1F+f5Wh0srI kCBYTOYz73l9XBNdZS2sQs86rgcbwDyQAbRjIxQ7Z7hsCk5F6Ufr3OXYej7njWZ4 tckrg5rLst9VrpPEE1INpY79QOXHDd6pRLtkzUAGxdJROb5csCMuCG/H5jgqq45b wa0JOyF69wWtaNQNhYbOW0jFidfVFNapMupbBs1nMSRYb7rXcXj4Ce2TPMKY5vfA SQVf+LnS6lec7fWSKUHm6SPlcbfHrMnkKpQ== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699527913; x=1699614313; bh=KH+d9CcaXbAlOVzyyZlEDaOLIAY4o9OGKQN GXZuhZ5w=; b=IEkpXcIoucoTI41Fa0oRPmoF+wqQtLBJ7jgj1KN42Dv1kPSyGLa q7e6xXsl0xpxN009MePEcMVJybspeLg8BBgK7tYw/xwMQjyQMz5h+0hIFYppIdHH ET2CE/2ny7yh/FaxhLUT+YdUnhCE0icjuh47etF44PsBOcicEAFm4zFFlDxR9ZhD 2EF4NavnPvY7fk1kbK98F6iYzjbu0iF9XopVI/RG/kDIZe4jMu7vpQS2Zh4idyVy H8GIjhjfFIiJMyzXTzL+xREblohbHJyo6ZrW58ZWjjYHPdE1bSORUNFirPzPOADR ij7RA08yBmuI0eEid64nh4cdMuVHnBS6xSg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvuddgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Nov 2023 06:05:11 -0500 (EST) Message-ID: Date: Thu, 9 Nov 2023 13:05:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <834jhv1lfw.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) 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.2 (---) On 09/11/2023 08:37, Eli Zaretskii wrote: >> Date: Wed, 8 Nov 2023 23:04:50 +0200 >> Cc:66993@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 08/11/2023 18:32, Eli Zaretskii wrote: >>> I thought these writes were already just adding projects, not >>> clobbering the list. >> The file is re-written in full every time e.g. to remove the previous >> mentions of a project that should now be moved to the top. > I don't understand how this resolves the concern about clobbering. If > each Emacs session just writes its list of projects to the file, > without refreshing the list due to additions done by another session, > they will still clobber each other's lists, no? This could be avoided > if the writer would read the file before rewriting it. Not resolves. Explains. > Can you tell why the list of projects is saved on a file that is > global among all sessions of the same user? Would it make sense to > make the file specific to an Emacs process? Specific, meaning in a file name e.g. suffixed with pid? And what happens after the restart? The list needs to be recovered. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2023 11:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169952932220550 (code B ref 66993); Thu, 09 Nov 2023 11:29:01 +0000 Received: (at 66993) by debbugs.gnu.org; 9 Nov 2023 11:28:42 +0000 Received: from localhost ([127.0.0.1]:46885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r13DF-0005LN-VG for submit@debbugs.gnu.org; Thu, 09 Nov 2023 06:28:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r13DD-0005LA-QB for 66993@debbugs.gnu.org; Thu, 09 Nov 2023 06:28:40 -0500 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 1r13CU-000310-Nx; Thu, 09 Nov 2023 06:27:54 -0500 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=twe2DANwAuMurutbl5I7eIbPQw0vx4btgDo6eWacLWY=; b=QfUo/D1hUGjX TZUX4x58F6UAiFqim/DbgI+3S9Po5cleV3dHU63GX/iP1hiWEAZFB5CfldLPkBn2pKMCzaCsibO4Q hX60ezULhGNpVESY9Vr0eDadeS093BKNtFgY6NhHQAv3e5dIOnXVJvXKPKsx9XO13guQvoEm2/Dgr zL6GnfzU6JzcR4sw2xN0bBZlBbtGMI2mai3cxaSomunRPTKp3v+5qF9gx2XNjO/1yM6NZavozWb+I eZjfoofIl5mfsxg+WDUVn9JmZarnGomBJ/U1H9/B1vcOT3I1rp8KaLqffo1hbpxFiqAReQnhCAjkl 8G1DvKx1NCO2Gyy38fNhdg==; Date: Thu, 09 Nov 2023 13:27:47 +0200 Message-Id: <83ttpvyxn0.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Dmitry Gutov on Thu, 9 Nov 2023 13:05:09 +0200) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.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 (---) > Date: Thu, 9 Nov 2023 13:05:09 +0200 > Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org > From: Dmitry Gutov > > > Can you tell why the list of projects is saved on a file that is > > global among all sessions of the same user? Would it make sense to > > make the file specific to an Emacs process? > > Specific, meaning in a file name e.g. suffixed with pid? For example, yes. > And what happens after the restart? The list needs to be recovered. Why does it need to be recovered? Isn't it built on-the-fly anyway? Is this just some kind of optimization? I guess I don't understand well enough why this file exists and how it is used? From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2023 11:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169952965921177 (code B ref 66993); Thu, 09 Nov 2023 11:35:01 +0000 Received: (at 66993) by debbugs.gnu.org; 9 Nov 2023 11:34:19 +0000 Received: from localhost ([127.0.0.1]:46890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r13Ig-0005VV-Oc for submit@debbugs.gnu.org; Thu, 09 Nov 2023 06:34:19 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:57417) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r13Ie-0005VD-Fn for 66993@debbugs.gnu.org; Thu, 09 Nov 2023 06:34:17 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3B2F75C0329; Thu, 9 Nov 2023 06:33:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 09 Nov 2023 06:33:32 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1699529612; x=1699616012; bh=EjWHzCNniHaSLcl7WNJ+noD5oodyFWgJTfF alFozTZA=; b=cfu9iaELLWy3khRFO7mC8AEpZ+bD3cul/ND5E23UK1QVlje1qC1 /mXTLn5M0XohZ42astVh+zJyZY5EtbL4mjTnfUfZIr7OO3wO4HmLchbYhpFwAyLQ BMWtAIYN5LCgitLpB2/Y5bGAmnSP5c1aWn6VRSfcJmOkiahVRJ1nWFTmyKZueeKn Vd3pDZAJcsHNoNIVfcABujMS7GqpKfJg009/kVpJbSaSB24rC7+o5dmE+uH2jfKB KoxMY85DOlCzw/efetVGq9G0Ou8NzXpBobMxxzhHcViS+Yoi+tu8NZTJxjRAN0qK ZoqO5N8c8r22cS+2oS5ltTHRI7i4Jla7UYQ== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699529612; x=1699616012; bh=EjWHzCNniHaSLcl7WNJ+noD5oodyFWgJTfF alFozTZA=; b=sT9r6PB1N5nlYnrnjimEzhc9yDJfxeMp6OdJm3VT/PaE6Gm+3+N zrWo39Q+BSTMd2uz64EDDllvhNN11gUHzNIe90+CdlzIbBwdzSPMzcMFqL/Kh8Pp Cr9mKblMYQoeSC9bUzZUWrN5HaoeZ2I4snm9G8L8aA3R0FLQuUGBRvX+fLetTOTU iIpGDJmNo6QVb2TxtNkAM2E67ztYucck3NbUQd1QGV7HF5lkWYxLJoYpewTkYfm+ wAxoFkkGDSOPJWlberFTmKoq2YUAh9C7rtUazr9mnk47SbKlRJgvagZ6fkiQ9LJs Dm/jR6wZCbgxbKry/G1UvL6Fj/Hbr4AxqVw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddvuddgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Nov 2023 06:33:31 -0500 (EST) Message-ID: <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> Date: Thu, 9 Nov 2023 13:33:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83ttpvyxn0.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) 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.2 (---) On 09/11/2023 13:27, Eli Zaretskii wrote: >> Date: Thu, 9 Nov 2023 13:05:09 +0200 >> Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org >> From: Dmitry Gutov >> >>> Can you tell why the list of projects is saved on a file that is >>> global among all sessions of the same user? Would it make sense to >>> make the file specific to an Emacs process? >> >> Specific, meaning in a file name e.g. suffixed with pid? > > For example, yes. > >> And what happens after the restart? The list needs to be recovered. > > Why does it need to be recovered? Isn't it built on-the-fly anyway? > Is this just some kind of optimization? If we didn't need to read it after restart, there would be no point in writing the list to disk. > I guess I don't understand well enough why this file exists and how it > is used? Same reason as for savehist-file. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2023 14:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169954150919574 (code B ref 66993); Thu, 09 Nov 2023 14:52:02 +0000 Received: (at 66993) by debbugs.gnu.org; 9 Nov 2023 14:51:49 +0000 Received: from localhost ([127.0.0.1]:47157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r16Nm-00055b-At for submit@debbugs.gnu.org; Thu, 09 Nov 2023 09:51:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39524) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r16Nh-00055G-7x for 66993@debbugs.gnu.org; Thu, 09 Nov 2023 09:51:44 -0500 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 1r16My-0002Aq-4J; Thu, 09 Nov 2023 09:50:56 -0500 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=3ZYH6gSVRF71b5yJlyuwOBWnPKw3JxPCA25+YAFl1ro=; b=E2ASf/c5ku02 ZDn3/F8ad4F65QtfvtOa+tOmPLkaW2r7CGahJ1GX+JlEpicyD2RQL7KIvEJzPh23q8/8jKHpLwbhA QyN5PAO1ZsEPzPGGhvtCm0HbWRLOfUF9BvdbkzA1TOuVve7yn62G23ngsYbjxGkJ+4CpF5Z1oN/Hl KoGj0+JUnEIeK4XqIw+YwUaMaB0vq4GMk9HiSwYI5WQV2REy55ERJ7vynagVVd0gIQq7gU5D38KWB C39+h6bZGs0LcXr1Xg6Ke6WS3R182sCQRtcHxBf6rEqZVFoTx0YkmLDY+pVXFU2VleZUMkg5zu0CD BpGZvydF7t5v2ghGrVnKuQ==; Date: Thu, 09 Nov 2023 16:50:32 +0200 Message-Id: <83r0kzyo93.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> (message from Dmitry Gutov on Thu, 9 Nov 2023 13:33:29 +0200) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@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, 9 Nov 2023 13:33:29 +0200 > Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org > From: Dmitry Gutov > > On 09/11/2023 13:27, Eli Zaretskii wrote: > >> Date: Thu, 9 Nov 2023 13:05:09 +0200 > >> Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org > >> From: Dmitry Gutov > >> > >> And what happens after the restart? The list needs to be recovered. > > > > Why does it need to be recovered? Isn't it built on-the-fly anyway? > > Is this just some kind of optimization? > > If we didn't need to read it after restart, there would be no point in > writing the list to disk. > > > I guess I don't understand well enough why this file exists and how it > > is used? > > Same reason as for savehist-file. It's a history of projects in the last session? Then it's one more reason to write the file only at exit, I guess? From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2023 16:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169954795419169 (code B ref 66993); Thu, 09 Nov 2023 16:40:02 +0000 Received: (at 66993) by debbugs.gnu.org; 9 Nov 2023 16:39:14 +0000 Received: from localhost ([127.0.0.1]:48628 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r183l-0004z7-Pr for submit@debbugs.gnu.org; Thu, 09 Nov 2023 11:39:14 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:34365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r183j-0004yr-5w for 66993@debbugs.gnu.org; Thu, 09 Nov 2023 11:39:12 -0500 From: Spencer Baugh In-Reply-To: <835y2b1lnp.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 09 Nov 2023 08:32:58 +0200") References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> <83il6c1ct3.fsf@gnu.org> <83fs1g19vn.fsf@gnu.org> <83bkc416q3.fsf@gnu.org> <835y2b1lnp.fsf@gnu.org> Date: Thu, 09 Nov 2023 11:38:26 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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: dmitry@gutov.dev, 66993@debbugs.gnu.org >> Date: Wed, 08 Nov 2023 15:43:53 -0500 >> >> Eli Zaretskii writes: >> >> >> (if noninteractive (error "Cannot resolve lock conflict in batch mode")) >> > >> > And that is not specific enough? >> >> Are you suggesting that we should condition-case and check the string >> inside the error is "Cannot resolve lock conflict in batch mode"? > > That's one way, yes. Another one is to use define-error to define a > new error type for this case. Instead of defining a new error type, how about just signaling file-locked instead? e.g. the following patch: diff --git a/lisp/userlock.el b/lisp/userlock.el index 61f061d3e54..e4d23c56249 100644 --- a/lisp/userlock.el +++ b/lisp/userlock.el @@ -67,7 +67,7 @@ ask-user-about-lock (message (substitute-command-keys "%s locked by %s: (\\`s', \\`q', \\`p', \\`?')? ") short-file short-opponent) - (if noninteractive (error "Cannot resolve lock conflict in batch mode")) + (if noninteractive (signal 'file-locked (list file opponent))) (let ((tem (let ((inhibit-quit t) (cursor-in-echo-area t)) (prog1 (downcase (read-char)) Including also a documentation update to explain that when noninteractive=t, a file lock conflict always signals file-locked instead of prompting the user. >> > And why the noninteractive=t case is relevant here, btw? >> >> Because we don't want to prompt the user, we just want to signal an >> error if there's a lock conflict. > > ??? Is project-current always used in a non-interactive context? I > don't think so. When some interactive program calls it, > noninteractive will be nil, and what userlock.el does in that case is > not what you describe. Right. > And if you are saying that some program binds noninteractive to a > non-nil value to avoid asking the file-locked question, then with the > error-catching as discussed above in place, that program won't need to > do that anymore, right? (Also see below for why this binding is > problematic in a more general sense.) Yes, that's what I'm saying. That's all correct. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2023 16:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169954879820968 (code B ref 66993); Thu, 09 Nov 2023 16:54:01 +0000 Received: (at 66993) by debbugs.gnu.org; 9 Nov 2023 16:53:18 +0000 Received: from localhost ([127.0.0.1]:48651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r18HN-0005S8-Vd for submit@debbugs.gnu.org; Thu, 09 Nov 2023 11:53:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r18HG-0005Rq-Pe for 66993@debbugs.gnu.org; Thu, 09 Nov 2023 11:53:16 -0500 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 1r18GX-00034J-TN; Thu, 09 Nov 2023 11:52:25 -0500 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=IkIPxOT7SPIhmlQU/a63n8ASMVduINakZFNNbcIotWc=; b=HUTklabC0hNl 31/IOpKUJwIa2QZoyfpoOQrAGks3yzyotqaw+AS20PpPILKuIr3fBbK+922dLrTwMQUyu9Q64wVyb cTgvKgppGJRG9kyGBOEj5pOivrv9RbcgbDegUTLU1V7r4h7ynB9DbXWHSm9XAoKdh5fddsVAjQynO YgVXGdFqJ5v1sG8q8OoCjktfdRhPXDphITJwDQoqIQuOnmYseAo5Ouq0NZjZ00PqvzHsDx+pBRTrL M0+wau6riulKjEJqc3ew7ohrFeWa3pK0dESggcIQ5lC54mwzdu1fL8+Uhcb9U4YUtefA+vYFFhjMT P8uixQxXEUBRIW/XmNdfPw==; Date: Thu, 09 Nov 2023 18:52:19 +0200 Message-Id: <83bkc2zx6k.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Thu, 09 Nov 2023 11:38:26 -0500) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> <83il6c1ct3.fsf@gnu.org> <83fs1g19vn.fsf@gnu.org> <83bkc416q3.fsf@gnu.org> <835y2b1lnp.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: dmitry@gutov.dev, 66993@debbugs.gnu.org > Date: Thu, 09 Nov 2023 11:38:26 -0500 > > > That's one way, yes. Another one is to use define-error to define a > > new error type for this case. > > Instead of defining a new error type, how about just signaling > file-locked instead? e.g. the following patch: > > diff --git a/lisp/userlock.el b/lisp/userlock.el > index 61f061d3e54..e4d23c56249 100644 > --- a/lisp/userlock.el > +++ b/lisp/userlock.el > @@ -67,7 +67,7 @@ ask-user-about-lock > (message (substitute-command-keys > "%s locked by %s: (\\`s', \\`q', \\`p', \\`?')? ") > short-file short-opponent) > - (if noninteractive (error "Cannot resolve lock conflict in batch mode")) > + (if noninteractive (signal 'file-locked (list file opponent))) > (let ((tem (let ((inhibit-quit t) > (cursor-in-echo-area t)) > (prog1 (downcase (read-char)) Please show the result of this change on what Emacs prints in batch mode when this error is signaled. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2023 18:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169955291914825 (code B ref 66993); Thu, 09 Nov 2023 18:02:01 +0000 Received: (at 66993) by debbugs.gnu.org; 9 Nov 2023 18:01:59 +0000 Received: from localhost ([127.0.0.1]:48690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r19Lr-0003r3-4Z for submit@debbugs.gnu.org; Thu, 09 Nov 2023 13:01:59 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:45663) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r19Lm-0003ql-FI for 66993@debbugs.gnu.org; Thu, 09 Nov 2023 13:01:57 -0500 From: Spencer Baugh In-Reply-To: <83bkc2zx6k.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 09 Nov 2023 18:52:19 +0200") References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> <83il6c1ct3.fsf@gnu.org> <83fs1g19vn.fsf@gnu.org> <83bkc416q3.fsf@gnu.org> <835y2b1lnp.fsf@gnu.org> <83bkc2zx6k.fsf@gnu.org> Date: Thu, 09 Nov 2023 13:01:09 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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: dmitry@gutov.dev, 66993@debbugs.gnu.org >> Date: Thu, 09 Nov 2023 11:38:26 -0500 >> >> > That's one way, yes. Another one is to use define-error to define a >> > new error type for this case. >> >> Instead of defining a new error type, how about just signaling >> file-locked instead? e.g. the following patch: >> >> diff --git a/lisp/userlock.el b/lisp/userlock.el >> index 61f061d3e54..e4d23c56249 100644 >> --- a/lisp/userlock.el >> +++ b/lisp/userlock.el >> @@ -67,7 +67,7 @@ ask-user-about-lock >> (message (substitute-command-keys >> "%s locked by %s: (\\`s', \\`q', \\`p', \\`?')? ") >> short-file short-opponent) >> - (if noninteractive (error "Cannot resolve lock conflict in batch mode")) >> + (if noninteractive (signal 'file-locked (list file opponent))) >> (let ((tem (let ((inhibit-quit t) >> (cursor-in-echo-area t)) >> (prog1 (downcase (read-char)) > > Please show the result of this change on what Emacs prints in batch > mode when this error is signaled. Before: $ ./src/emacs -Q --batch --eval '(write-region "foo" nil "~/file")' /home/sbaugh/file locked by sbaugh@igm-qw... (pid 3781848): (s, q, p, ?)? Error: error ("Cannot resolve lock conflict in batch mode") mapbacktrace(#f(compiled-function (evald func args flags) #)) debug-early-backtrace() debug-early(error (error "Cannot resolve lock conflict in batch mode")) signal(error ("Cannot resolve lock conflict in batch mode")) error("Cannot resolve lock conflict in batch mode") ask-user-about-lock("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)") write-region("foo" nil "~/file") eval((write-region "foo" nil "~/file") t) command-line-1(("--eval" "(write-region \"foo\" nil \"~/file\")")) command-line() normal-top-level() Cannot resolve lock conflict in batch mode After: $ ./src/emacs -Q --batch --eval '(write-region "foo" nil "~/file")' /home/sbaugh/file locked by sbaugh@igm-qw... (pid 3781848): (s, q, p, ?)? Error: file-locked ("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)") mapbacktrace(#f(compiled-function (evald func args flags) #)) debug-early-backtrace() debug-early(error (file-locked "/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)")) signal(file-locked ("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)")) ask-user-about-lock("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)") write-region("foo" nil "~/file") eval((write-region "foo" nil "~/file") t) command-line-1(("--eval" "(write-region \"foo\" nil \"~/file\")")) command-line() normal-top-level() /home/sbaugh/file: sbaugh@igm-qws-u22796a (pid 3781848) From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2023 19:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169955927426709 (code B ref 66993); Thu, 09 Nov 2023 19:48:02 +0000 Received: (at 66993) by debbugs.gnu.org; 9 Nov 2023 19:47:54 +0000 Received: from localhost ([127.0.0.1]:49060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r1B0L-0006wj-Hf for submit@debbugs.gnu.org; Thu, 09 Nov 2023 14:47:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r1B0I-0006wT-4w for 66993@debbugs.gnu.org; Thu, 09 Nov 2023 14:47:52 -0500 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 1r1AzY-0000vv-P4; Thu, 09 Nov 2023 14:47:04 -0500 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=eaPYHX4HDcq+q3sVTOA6mgm73mONyh5HRkvbPYgp8ao=; b=dZ5+YDWWwEPB 22xY547Y07Dkl8V2Za3VBTtglewM4k3BcE1b7zzz1cAr1gwMVDaAHv0K1/Som4iPEBfJNP6Qn9rDK N8ALdFqVnVYNEpg8M0hnaDKTpwEQZ7Kg240ye/euQ4uVe+aNbDXFM1/JHGCy4gCJkRIfmrm4zBSIc qqKyWKArUW4bdFzKC/KffF2unETnPyBBXJ5qLgRi4mf5EAvXyCsi7F9VvKoi5KvxUbxFh5S2AvdHy aXO25jDDaqfw7NWss8XbKylwx/TIAXCi+1zI+E0cIEqMqZ9PO8I9gz/xq37/GGXtRvnmos2FV4ilj u3p1aVdTB/bHxOKL+w3VfQ==; Date: Thu, 09 Nov 2023 21:46:53 +0200 Message-Id: <837cmqzp3m.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Thu, 09 Nov 2023 13:01:09 -0500) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> <83il6c1ct3.fsf@gnu.org> <83fs1g19vn.fsf@gnu.org> <83bkc416q3.fsf@gnu.org> <835y2b1lnp.fsf@gnu.org> <83bkc2zx6k.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: dmitry@gutov.dev, 66993@debbugs.gnu.org > Date: Thu, 09 Nov 2023 13:01:09 -0500 > > Eli Zaretskii writes: > > Please show the result of this change on what Emacs prints in batch > > mode when this error is signaled. > > Before: > > $ ./src/emacs -Q --batch --eval '(write-region "foo" nil "~/file")' > /home/sbaugh/file locked by sbaugh@igm-qw... (pid 3781848): (s, q, p, ?)? > > Error: error ("Cannot resolve lock conflict in batch mode") > mapbacktrace(#f(compiled-function (evald func args flags) #)) > debug-early-backtrace() > debug-early(error (error "Cannot resolve lock conflict in batch mode")) > signal(error ("Cannot resolve lock conflict in batch mode")) > error("Cannot resolve lock conflict in batch mode") > ask-user-about-lock("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)") > write-region("foo" nil "~/file") > eval((write-region "foo" nil "~/file") t) > command-line-1(("--eval" "(write-region \"foo\" nil \"~/file\")")) > command-line() > normal-top-level() > Cannot resolve lock conflict in batch mode > > > After: > > $ ./src/emacs -Q --batch --eval '(write-region "foo" nil "~/file")' > /home/sbaugh/file locked by sbaugh@igm-qw... (pid 3781848): (s, q, p, ?)? > > Error: file-locked ("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)") > mapbacktrace(#f(compiled-function (evald func args flags) #)) > debug-early-backtrace() > debug-early(error (file-locked "/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)")) > signal(file-locked ("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)")) > ask-user-about-lock("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)") > write-region("foo" nil "~/file") > eval((write-region "foo" nil "~/file") t) > command-line-1(("--eval" "(write-region \"foo\" nil \"~/file\")")) > command-line() > normal-top-level() > /home/sbaugh/file: sbaugh@igm-qws-u22796a (pid 3781848) Thanks, that's what I thought: this loses information. The "Cannot resolve lock conflict in batch mode" part is important, since it explains the "file-locked" part. So please include the missing text in the list passed to 'signal' as its DATA argument, so as not to lose this explanation. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Nov 2023 12:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: Spencer Baugh , 66993@debbugs.gnu.org, dmitry@gutov.dev Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169962056610597 (code B ref 66993); Fri, 10 Nov 2023 12:50:02 +0000 Received: (at 66993) by debbugs.gnu.org; 10 Nov 2023 12:49:26 +0000 Received: from localhost ([127.0.0.1]:49667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r1Qwv-0002ko-Gv for submit@debbugs.gnu.org; Fri, 10 Nov 2023 07:49:26 -0500 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:47286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r1Qwr-0002k1-Au for 66993@debbugs.gnu.org; Fri, 10 Nov 2023 07:49:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: cc:content-type:from:subject:to; s=s1; bh=xm5aPNITI8epldU732aFYyRg6uyPgNKUIlV9bD2xpzY=; b=eRHfZC9XgKgRTfo7kNQSw4uMNJgt1t1Z2HBDg3zHnqXawL+v7mzg8JztbtrdQZu68fJy Ba2m88h+B6XhQI/+lJ4hntkbGpyI5hnS3UH/J0yphpdX72rU0tDqnZdLMRvduex2D2vGns CWQWK67VhFhv6lIlGj1bGTbi9yVRYZbg6H8uiHaJnEO3Px+UJOEzvavZ/emDLamSqoOu0g Dvf6Z0ByhdVrLLV5bdNtyCfu93RaV95UNzbcBbNOUL0NGtkpXERzNAjtLKnie68JTLX308 3+iSfxJHK1pXMjFEpOUklNZoZ9r8pifWo2lJzc6PxGVONUxaWSnW774Z/n2gc2Sw== Received: by filterdrecv-6b68c9f446-nmqjr with SMTP id filterdrecv-6b68c9f446-nmqjr-1-654E26A3-27 2023-11-10 12:48:35.964428326 +0000 UTC m=+2052459.980717577 Received: from earth.catern.com (unknown) by geopod-ismtpd-10 (SG) with ESMTP id 98GJk5NwQnG-ilZEQe3uMw Fri, 10 Nov 2023 12:48:35.791 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=100.38.103.73; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Received: from localhost (unknown [100.38.103.73]) by earth.catern.com (Postfix) with ESMTPSA id 8461E62D3B; Fri, 10 Nov 2023 07:48:30 -0500 (EST) From: Spencer Baugh In-Reply-To: <837cmqzp3m.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 09 Nov 2023 21:46:53 +0200") References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> <83il6c1ct3.fsf@gnu.org> <83fs1g19vn.fsf@gnu.org> <83bkc416q3.fsf@gnu.org> <835y2b1lnp.fsf@gnu.org> <83bkc2zx6k.fsf@gnu.org> <837cmqzp3m.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Fri, 10 Nov 2023 12:48:36 +0000 (UTC) Message-ID: <8734xd7p0h.fsf@catern.com> MIME-Version: 1.0 X-SG-EID: GW3oCMoYnalRiojMOuLzE6x2H5kORXvlCdz1UwQVRMVT4fbh9ODEfCogOe74cOrI4e0V+MFZgakz9Re5a6/CgshKD0t4Du4HyCzIJyhzmcmqyedRQhuuB6dA9O040QpFRgAXAkzciSf+zDnqerHi3i5M4/UEMQY+2Ob0EB8zn6kbjmRJcWjzpC4q+d1Bsl2YuC19iaZsusu0NKwxAjA2+io3i8b6kl5JQNbh6BrOFK3p7ZjAh+QS5Ub74ybJ3dbv X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.8 (/) 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: -0.2 (/) --=-=-= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org >> Date: Thu, 09 Nov 2023 13:01:09 -0500 >> >> Eli Zaretskii writes: >> > Please show the result of this change on what Emacs prints in batch >> > mode when this error is signaled. >> >> Before: >> >> $ ./src/emacs -Q --batch --eval '(write-region "foo" nil "~/file")' >> /home/sbaugh/file locked by sbaugh@igm-qw... (pid 3781848): (s, q, p, ?)? >> >> Error: error ("Cannot resolve lock conflict in batch mode") >> mapbacktrace(#f(compiled-function (evald func args flags) #)) >> debug-early-backtrace() >> debug-early(error (error "Cannot resolve lock conflict in batch mode")) >> signal(error ("Cannot resolve lock conflict in batch mode")) >> error("Cannot resolve lock conflict in batch mode") >> ask-user-about-lock("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)") >> write-region("foo" nil "~/file") >> eval((write-region "foo" nil "~/file") t) >> command-line-1(("--eval" "(write-region \"foo\" nil \"~/file\")")) >> command-line() >> normal-top-level() >> Cannot resolve lock conflict in batch mode >> >> >> After: >> >> $ ./src/emacs -Q --batch --eval '(write-region "foo" nil "~/file")' >> /home/sbaugh/file locked by sbaugh@igm-qw... (pid 3781848): (s, q, p, ?)? >> >> Error: file-locked ("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)") >> mapbacktrace(#f(compiled-function (evald func args flags) #)) >> debug-early-backtrace() >> debug-early(error (file-locked "/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)")) >> signal(file-locked ("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)")) >> ask-user-about-lock("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)") >> write-region("foo" nil "~/file") >> eval((write-region "foo" nil "~/file") t) >> command-line-1(("--eval" "(write-region \"foo\" nil \"~/file\")")) >> command-line() >> normal-top-level() >> /home/sbaugh/file: sbaugh@igm-qws-u22796a (pid 3781848) > > Thanks, that's what I thought: this loses information. The "Cannot > resolve lock conflict in batch mode" part is important, since it > explains the "file-locked" part. So please include the missing text > in the list passed to 'signal' as its DATA argument, so as not to lose > this explanation. OK, how about this? Which makes Emacs print: Error: file-locked ("/home/sbaugh/file" "sbaugh@earth (pid 1852838)" "Cannot resolve lock conflict in batch mode") mapbacktrace(#f(compiled-function (evald func args flags) #)) debug-early-backtrace() debug-early(error (file-locked "/home/sbaugh/file" "sbaugh@earth (pid 1852838)" "Cannot resolve lock conflict in batch mode")) signal(file-locked ("/home/sbaugh/file" "sbaugh@earth (pid 1852838)" "Cannot resolve lock conflict in batch mode")) ask-user-about-lock("/home/sbaugh/file" "sbaugh@earth (pid 1852838)") write-region("foo" nil "~/file") eval((write-region "foo" nil "~/file") t) command-line-1(("--eval" "(write-region \"foo\" nil \"~/file\")")) command-line() normal-top-level() /home/sbaugh/file: sbaugh@earth (pid 1852838), Cannot resolve lock conflict in batch mode --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Signal-file-locked-on-lock-conflict-with-noninteract.patch >From 9f94d8975406a3f4bdaa97ed8bd6a08dbf8e3d9b Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Fri, 10 Nov 2023 07:20:09 -0500 Subject: [PATCH] Signal file-locked on lock conflict with noninteractive=t Previously we would signal a generic error on lock conflict when noninteractive=t. That meant that non-interactively handling a lock conflict would require catching all errors and checking the string in DATA. Now we just signal file-locked instead, which matches the interactive behavior when the user says "q" at the prompt. Also, when noninteractive, we signal before we write the prompt about the lock conflict. That prompt usually gets in the way of noninteractively handling and suppress lock conflict errors. The signal data contains all the necessary information, we don't need to write a separate message for noninteractive. * lisp/userlock.el (ask-user-about-lock): Signal file-locked on noninteractive lock conflict. (bug#66993) --- lisp/userlock.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/userlock.el b/lisp/userlock.el index 4623608f1db..91d5b7308dd 100644 --- a/lisp/userlock.el +++ b/lisp/userlock.el @@ -64,10 +64,11 @@ ask-user-about-lock (match-string 0 opponent))) opponent)) (while (null answer) + (when noninteractive + (signal 'file-locked (list file opponent "Cannot resolve lock conflict in batch mode"))) (message (substitute-command-keys "%s locked by %s: (\\`s', \\`q', \\`p', \\`?')? ") short-file short-opponent) - (if noninteractive (error "Cannot resolve lock conflict in batch mode")) (let ((tem (let ((inhibit-quit t) (cursor-in-echo-area t)) (prog1 (downcase (read-char)) -- 2.39.2 --=-=-=-- From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Nov 2023 15:42:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: Dmitry Gutov , 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.17000628632280 (code B ref 66993); Wed, 15 Nov 2023 15:42:06 +0000 Received: (at 66993) by debbugs.gnu.org; 15 Nov 2023 15:41:03 +0000 Received: from localhost ([127.0.0.1]:52910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r3I0T-0000Zs-HF for submit@debbugs.gnu.org; Wed, 15 Nov 2023 10:41:01 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:49163) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r3I0M-0000ZW-9R for 66993@debbugs.gnu.org; Wed, 15 Nov 2023 10:40:39 -0500 From: Spencer Baugh In-Reply-To: <83r0kzyo93.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 09 Nov 2023 16:50:32 +0200") References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> Date: Wed, 15 Nov 2023 10:40:33 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain 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: >> Date: Thu, 9 Nov 2023 13:33:29 +0200 >> Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 09/11/2023 13:27, Eli Zaretskii wrote: >> >> Date: Thu, 9 Nov 2023 13:05:09 +0200 >> >> Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org >> >> From: Dmitry Gutov >> >> >> >> And what happens after the restart? The list needs to be recovered. >> > >> > Why does it need to be recovered? Isn't it built on-the-fly anyway? >> > Is this just some kind of optimization? >> >> If we didn't need to read it after restart, there would be no point in >> writing the list to disk. >> >> > I guess I don't understand well enough why this file exists and how it >> > is used? >> >> Same reason as for savehist-file. > > It's a history of projects in the last session? Then it's one more > reason to write the file only at exit, I guess? This comparison to savehist-file actually makes me think: Why don't we just make project--list into a history variable, and persist it like savehist? It would already be quite nice to have a history variable project-history for project-prompter, I've been thinking about implementing that. It would be convenient for: - switching repeatedly between two projects - running a project command accidentally outside a project and wanting to run it in the most recently used project. But then, if we have project-history, could the project file just be a persisted project-history? If we had this model, project-remember-project would be basically (push project 'project-history) project-forget-zombie-projects would naturally not be needed, because any zombie projects wouldn't be visited as part of the project-history, and so if the history was limited in size, they'd eventually just drop off the end. project-switch-project would prompt for anything on project-history. I think it simplifies things quite a lot! From unknown Thu Sep 11 09:17:54 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#66993: closed (Re: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock) Message-ID: References: <83r0krqgqb.fsf@gnu.org> X-Gnu-PR-Message: they-closed 66993 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: patch Reply-To: 66993@debbugs.gnu.org Date: Wed, 15 Nov 2023 16:08:04 +0000 Content-Type: multipart/mixed; boundary="----------=_1700064484-5844-1" This is a multi-part message in MIME format... ------------=_1700064484-5844-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #66993: [PATCH] project.el: avoid asking user about project-list-file lock 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 66993@debbugs.gnu.org. --=20 66993: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D66993 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1700064484-5844-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 66993-done) by debbugs.gnu.org; 15 Nov 2023 16:07:43 +0000 Received: from localhost ([127.0.0.1]:53011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r3IQY-0001TS-W3 for submit@debbugs.gnu.org; Wed, 15 Nov 2023 11:07:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r3IQS-0001QS-L5 for 66993-done@debbugs.gnu.org; Wed, 15 Nov 2023 11:07:37 -0500 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 1r3G6A-00027A-6m; Wed, 15 Nov 2023 08:38:30 -0500 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=9IGT1VJ+cgWwENqZHdJoUcdPkVfWu6Z+JwVu0dZyKNQ=; b=OQu6XHHY2XJh QcuQ6O3vciLmrRJwwKr4k2i//fPkOpyhOG3IAHIlEdbjwwqjBz8l+tUbZ7ZN0vl3FRlkQS46tAszR b8o1FZ5GkU4z9C5E0z8Skmrb57HVJIRXBwZL+DgvvkgALuqI69CDFOw/7oAErFbwvKZQHuW18SMSc AzsG22y4ayZbm5cyAyJyetfW1PcBiG1d/3Pys0BhxgWn4yXFixRbQ1obSE7AJf7KrYVSie/kodIa4 geuXno7qlfGo8mKc0f09OrZiyprJHc8/suqKH2r1AqZ3Lc8iTz1ti1cR5PmMl97PsNxxX0JoCJwPY roaqcNzsHLlZYy21s+BXhA==; Date: Wed, 15 Nov 2023 15:38:20 +0200 Message-Id: <83r0krqgqb.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: <8734xd7p0h.fsf@catern.com> (message from Spencer Baugh on Fri, 10 Nov 2023 12:48:36 +0000 (UTC)) Subject: Re: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83jzqs1hhx.fsf@gnu.org> <57c079bf-e3a3-db45-c45a-ad6925335e2f@gutov.dev> <83il6c1ct3.fsf@gnu.org> <83fs1g19vn.fsf@gnu.org> <83bkc416q3.fsf@gnu.org> <835y2b1lnp.fsf@gnu.org> <83bkc2zx6k.fsf@gnu.org> <837cmqzp3m.fsf@gnu.org> <8734xd7p0h.fsf@catern.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66993-done Cc: sbaugh@janestreet.com, 66993-done@debbugs.gnu.org, dmitry@gutov.dev 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: Fri, 10 Nov 2023 12:48:36 +0000 (UTC) > Cc: Spencer Baugh , dmitry@gutov.dev, > 66993@debbugs.gnu.org > > > Thanks, that's what I thought: this loses information. The "Cannot > > resolve lock conflict in batch mode" part is important, since it > > explains the "file-locked" part. So please include the missing text > > in the list passed to 'signal' as its DATA argument, so as not to lose > > this explanation. > > OK, how about this? Which makes Emacs print: > > Error: file-locked ("/home/sbaugh/file" "sbaugh@earth (pid 1852838)" "Cannot resolve lock conflict in batch mode") > mapbacktrace(#f(compiled-function (evald func args flags) #)) > debug-early-backtrace() > debug-early(error (file-locked "/home/sbaugh/file" "sbaugh@earth (pid 1852838)" "Cannot resolve lock conflict in batch mode")) > signal(file-locked ("/home/sbaugh/file" "sbaugh@earth (pid 1852838)" "Cannot resolve lock conflict in batch mode")) > ask-user-about-lock("/home/sbaugh/file" "sbaugh@earth (pid 1852838)") > write-region("foo" nil "~/file") > eval((write-region "foo" nil "~/file") t) > command-line-1(("--eval" "(write-region \"foo\" nil \"~/file\")")) > command-line() > normal-top-level() > /home/sbaugh/file: sbaugh@earth (pid 1852838), Cannot resolve lock conflict in batch mode Thanks, installed on master, and closing the bug. ------------=_1700064484-5844-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 7 Nov 2023 21:28:56 +0000 Received: from localhost ([127.0.0.1]:43437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0Td1-0008St-RE for submit@debbugs.gnu.org; Tue, 07 Nov 2023 16:28:56 -0500 Received: from lists.gnu.org ([2001:470:142::17]:42192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0Tcz-0008Sf-0G for submit@debbugs.gnu.org; Tue, 07 Nov 2023 16:28:53 -0500 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 1r0TcG-0004aa-H8 for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 16:28:08 -0500 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 1r0TcE-0005Ay-Sf for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 16:28:08 -0500 From: Spencer Baugh To: bug-gnu-emacs@gnu.org Subject: [PATCH] project.el: avoid asking user about project-list-file lock Date: Tue, 07 Nov 2023 16:28:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) 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: -0.1 (/) --=-=-= Content-Type: text/plain Tags: patch This fixes a periodic issue that happens with multiple Emacs instances and project.el. Maybe this isn't the right way to change the behavior of ask-user-about-lock though; possibly we should add some new defcustom to customize it. Happy to do that if that's preferred. In GNU Emacs 29.1.50 (build 15, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2023-10-25 built on igm-qws-u22796a Repository revision: 5cbca757f620c7b4ca31776711a247b8f266c36e Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.8 (Green Obsidian) Configured using: 'configure --config-cache --with-x-toolkit=lucid --with-gif=ifavailable' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-project.el-avoid-asking-user-about-project-list-file.patch >From ec6caaf9fcb913847278f7183e46d3026c6986fb Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Tue, 7 Nov 2023 16:24:26 -0500 Subject: [PATCH] project.el: avoid asking user about project-list-file lock There are several features which will cause Emacs to frequently call project-current, and therefore call project-remember-project, and therefore sometimes call project--write-project-list whenever a new project is seen. - project-uniquify-dirname-transform will call this for each new buffer - project-mode-line will call this on mode-line update - My own private project-watch will call this based on file-notify events. If a user has multiple Emacs instances open using one or more of these features, it's fairly easy for both of the Emacs instances to see a new project at the same time. In that case, they'll both call project--write-project-list at the same time, which will clash and run ask-user-about-lock. This will happen frequently if the user is often looking at new projects. There's no correct answer the user can give to ask-user-about-lock: either way, one of the Emacs instances will have its project-list-file update lost. So let's not even bother prompting the user: just do nothing if project-list-file is currently locked. In the long run, the update doesn't actually get lost, because the Emacs instance will probably make the same project-list-file update again a few seconds later due to a later call to project-current. So this doesn't lose anything. * lisp/progmodes/project.el (project--write-project-list): No-op if the file is locked. --- lisp/progmodes/project.el | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 43c78f8b16b..78aaa75de5f 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1719,7 +1719,13 @@ project--write-project-list (expand-file-name name))))) project--list) (current-buffer))) - (write-region nil nil filename nil 'silent)))) + ;; If project-list-file is locked by some other Emacs, fail to + ;; write rather than prompting the user. + (ignore-error file-locked + (cl-letf (((symbol-function 'ask-user-about-lock) + (lambda (file opponent) + (signal 'file-locked (list file opponent))))) + (write-region nil nil filename nil 'silent)))))) ;;;###autoload (defun project-remember-project (pr &optional no-write) -- 2.39.3 --=-=-=-- ------------=_1700064484-5844-1-- From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Nov 2023 20:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: Dmitry Gutov , 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.170008135814494 (code B ref 66993); Wed, 15 Nov 2023 20:50:02 +0000 Received: (at 66993) by debbugs.gnu.org; 15 Nov 2023 20:49:18 +0000 Received: from localhost ([127.0.0.1]:53951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r3Mp3-0003lh-CI for submit@debbugs.gnu.org; Wed, 15 Nov 2023 15:49:18 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:55471) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r3Mp1-0003lJ-FX for 66993@debbugs.gnu.org; Wed, 15 Nov 2023 15:49:16 -0500 From: Spencer Baugh In-Reply-To: (Spencer Baugh's message of "Wed, 15 Nov 2023 10:40:33 -0500") References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> Date: Wed, 15 Nov 2023 15:49:11 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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 (-) --=-=-= Content-Type: text/plain Spencer Baugh writes: > Eli Zaretskii writes: >>> Date: Thu, 9 Nov 2023 13:33:29 +0200 >>> Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org >>> From: Dmitry Gutov >>> >>> On 09/11/2023 13:27, Eli Zaretskii wrote: >>> >> Date: Thu, 9 Nov 2023 13:05:09 +0200 >>> >> Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org >>> >> From: Dmitry Gutov >>> >> >>> >> And what happens after the restart? The list needs to be recovered. >>> > >>> > Why does it need to be recovered? Isn't it built on-the-fly anyway? >>> > Is this just some kind of optimization? >>> >>> If we didn't need to read it after restart, there would be no point in >>> writing the list to disk. >>> >>> > I guess I don't understand well enough why this file exists and how it >>> > is used? >>> >>> Same reason as for savehist-file. >> >> It's a history of projects in the last session? Then it's one more >> reason to write the file only at exit, I guess? > > This comparison to savehist-file actually makes me think: Why don't we > just make project--list into a history variable, and persist it like > savehist? > > It would already be quite nice to have a history variable > project-history for project-prompter, I've been thinking about > implementing that. It would be convenient for: > > - switching repeatedly between two projects > > - running a project command accidentally outside a project and wanting > to run it in the most recently used project. > > But then, if we have project-history, could the project file just be a > persisted project-history? > > If we had this model, project-remember-project would be basically > (push project 'project-history) > > project-forget-zombie-projects would naturally not be needed, because > any zombie projects wouldn't be visited as part of the project-history, > and so if the history was limited in size, they'd eventually just drop > off the end. > > project-switch-project would prompt for anything on project-history. > > I think it simplifies things quite a lot! Here's a patch which implements this. It drops compatibility with the existing project-file, just to demonstrate the simplicity of this approach. project--list is the new history variable. Using it is mostly trivial; a small bit of work is necessary in project-prompt-project-name to get project-names for the history, but that worked out great. Everything else just seems to work. And with savehist-mode enabled, project--list just gets stored automatically without any code in project.el. I can implement a backwards-compatible version if this seems like a reasonable direction to go in. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Incompatibly-change-project-list-to-be-a-project-his.patch >From 86714ac9c82967e9d93e32d9bd172311fc4aed00 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Wed, 15 Nov 2023 15:44:03 -0500 Subject: [PATCH] Incompatibly change project--list to be a project history variable With savehist-mode enabled, this Just Works. --- lisp/progmodes/project.el | 114 +++++++++++--------------------------- 1 file changed, 33 insertions(+), 81 deletions(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 95db9d0ef4c..59404e5729d 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1671,70 +1671,16 @@ project-kill-buffers ;;; Project list -(defcustom project-list-file (locate-user-emacs-file "projects") - "File in which to save the list of known projects." - :type 'file - :version "28.1" - :group 'project) - -(defvar project--list 'unset - "List structure containing root directories of known projects. -With some possible metadata (to be decided).") - -(defun project--read-project-list () - "Initialize `project--list' using contents of `project-list-file'." - (let ((filename project-list-file)) - (setq project--list - (when (file-exists-p filename) - (with-temp-buffer - (insert-file-contents filename) - (mapcar - (lambda (elem) - (let ((name (car elem))) - (list (if (file-remote-p name) name - (abbreviate-file-name name))))) - (read (current-buffer)))))) - (unless (seq-every-p - (lambda (elt) (stringp (car-safe elt))) - project--list) - (warn "Contents of %s are in wrong format, resetting" - project-list-file) - (setq project--list nil)))) - -(defun project--ensure-read-project-list () - "Initialize `project--list' if it isn't already initialized." - (when (eq project--list 'unset) - (project--read-project-list))) - -(defun project--write-project-list () - "Save `project--list' in `project-list-file'." - (let ((filename project-list-file)) - (with-temp-buffer - (insert ";;; -*- lisp-data -*-\n") - (let ((print-length nil) - (print-level nil)) - (pp (mapcar (lambda (elem) - (let ((name (car elem))) - (list (if (file-remote-p name) name - (expand-file-name name))))) - project--list) - (current-buffer))) - (write-region nil nil filename nil 'silent)))) +(defvar project--list nil + "List of root directories of recently-accessed projects.") ;;;###autoload -(defun project-remember-project (pr &optional no-write) - "Add project PR to the front of the project list. -Save the result in `project-list-file' if the list of projects -has changed, and NO-WRITE is nil." - (project--ensure-read-project-list) +(defun project-remember-project (pr &optional _no-write) + "Add project PR to the front of the project list." (let ((dir (abbreviate-file-name (project-root pr)))) - (unless (equal (caar project--list) dir) - (dolist (ent project--list) - (when (equal dir (car ent)) - (setq project--list (delq ent project--list)))) - (push (list dir) project--list) - (unless no-write - (project--write-project-list))))) + (unless (equal (car project--list) dir) + (setq project--list (delq dir project--list)) + (push dir project--list)))) (defun project--remove-from-project-list (project-root report-message) "Remove directory PROJECT-ROOT of a missing project from the project list. @@ -1742,11 +1688,9 @@ project--remove-from-project-list result in `project-list-file'. Announce the project's removal from the list using REPORT-MESSAGE, which is a format string passed to `message' as its first argument." - (project--ensure-read-project-list) - (when-let ((ent (assoc (abbreviate-file-name project-root) project--list))) - (setq project--list (delq ent project--list)) - (message report-message project-root) - (project--write-project-list))) + (let ((dir (abbreviate-file-name project-root))) + (setq project--list (delq dir project--list)) + (message report-message project-root))) ;;;###autoload (defun project-forget-project (project-root) @@ -1762,7 +1706,6 @@ project-prompt-project-dir The project is chosen among projects known from the project list, see `project-list-file'. It's also possible to enter an arbitrary directory not in the list." - (project--ensure-read-project-list) (let* ((dir-choice "... (choose a dir)") (choices ;; XXX: Just using this for the category (for the substring @@ -1772,43 +1715,55 @@ project-prompt-project-dir (pr-dir "")) (while (equal pr-dir "") ;; If the user simply pressed RET, do this again until they don't. - (setq pr-dir (completing-read "Select project: " choices nil t))) + (setq pr-dir (completing-read "Select project: " choices nil t nil 'project--list))) (if (equal pr-dir dir-choice) (read-directory-name "Select directory: " default-directory nil t) pr-dir))) +(defvar project--name-history) + (defun project-prompt-project-name () "Prompt the user for a project, by name, that is one of the known project roots. The project is chosen among projects known from the project list, see `project-list-file'. It's also possible to enter an arbitrary directory not in the list." (let* ((dir-choice "... (choose a dir)") + project--name-history (choices (let (ret) - (dolist (dir (project-known-project-roots)) + ;; Iterate in reverse order so project--name-history is in + ;; the correct order. + (dolist (dir (reverse project--list)) ;; we filter out directories that no longer map to a project, ;; since they don't have a clean project-name. - (if-let (proj (project--find-in-directory dir)) - (push (cons (project-name proj) proj) ret))) + (when-let (proj (project--find-in-directory dir)) + (let ((name (project-name proj))) + (push name project--name-history) + (push (cons name proj) ret)))) ret)) ;; XXX: Just using this for the category (for the substring ;; completion style). (table (project--file-completion-table - (reverse (cons dir-choice choices)))) + (cons dir-choice choices))) (pr-name "")) + (setq project--name-history (delete-consecutive-dups project--name-history)) (while (equal pr-name "") ;; If the user simply pressed RET, do this again until they don't. - (setq pr-name (completing-read "Select project: " table nil t))) + (setq pr-name + (completing-read "Select project: " table nil t nil 'project--name-history))) (if (equal pr-name dir-choice) (read-directory-name "Select directory: " default-directory nil t) - (let ((proj (assoc pr-name choices))) - (if (stringp proj) proj (project-root (cdr proj))))))) + (let* ((proj (assoc pr-name choices)) + (ret (project-root (cdr proj)))) + ;; Record this return value in history, since + ;; project--name-history is purely local. + (push ret project--list) + ret)))) ;;;###autoload (defun project-known-project-roots () "Return the list of root directories of all known projects." - (project--ensure-read-project-list) - (mapcar #'car project--list)) + project--list) ;;;###autoload (defun project-execute-extended-command () @@ -1865,14 +1820,13 @@ project-remember-projects-under the progress. The function returns the number of detected projects." (interactive "DDirectory: \nP") - (project--ensure-read-project-list) (let ((dirs (if recursive (directory-files-recursively dir "" t) (directory-files dir t))) (known (make-hash-table :size (* 2 (length project--list)) :test #'equal)) (count 0)) - (dolist (project (mapcar #'car project--list)) + (dolist (project project--list) (puthash project t known)) (dolist (subdir dirs) (when-let (((file-directory-p subdir)) @@ -1885,7 +1839,6 @@ project-remember-projects-under (setq count (1+ count)))) (if (zerop count) (message "No projects were found") - (project--write-project-list) (message "%d project%s were found" count (if (= count 1) "" "s"))) count)) @@ -1916,7 +1869,6 @@ project-forget-projects-under (setq count (1+ count))))) (if (zerop count) (message "No projects were forgotten") - (project--write-project-list) (message "%d project%s were forgotten" count (if (= count 1) "" "s"))) count)) -- 2.39.3 --=-=-=-- From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Nov 2023 01:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh , Eli Zaretskii Cc: 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.170027167514785 (code B ref 66993); Sat, 18 Nov 2023 01:42:01 +0000 Received: (at 66993) by debbugs.gnu.org; 18 Nov 2023 01:41:15 +0000 Received: from localhost ([127.0.0.1]:47339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4AKh-0003qP-Fk for submit@debbugs.gnu.org; Fri, 17 Nov 2023 20:41:15 -0500 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:53033) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4AKf-0003qB-BY for 66993@debbugs.gnu.org; Fri, 17 Nov 2023 20:41:14 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 007A4320092E; Fri, 17 Nov 2023 20:41:06 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 17 Nov 2023 20:41:07 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1700271666; x=1700358066; bh=SW4icyOR4zRxHNVrqryeDifzzfVSna/XHz9 IxULekxs=; b=TqMSEG+YfQTHgENDeJ9YB7jDUqRqqPTQ7CbOCeRvr7SGDhdAw9p P11pRBW1YoOLggaqtfBTiFkiOMdA4EOnf40nwGHElIFow/Es+6xmhag3kD7+D25K 5QHWewkb3Pv26xEWCwmzanv8bew18Kdg56YYsW2qmF/L30oIdXBTmibZlJl0keKD v97ELGHhavjK5Ww1T6Ul8dtn6RFYTuaiQ6+aqnh7fLDLr/ZG9fpmq9xnKSGryJg9 QiBrVpKOLiBYSaT8LEGQQszj88NeyeeXGrGiDLmnaKk8bSlYHdELw/q7L+AolM9C Jk+FT+Tf4TDahQ5HYDYBC2MiotOuCAhOixQ== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700271666; x=1700358066; bh=SW4icyOR4zRxHNVrqryeDifzzfVSna/XHz9 IxULekxs=; b=zoFgFdh4DYh2fugb4gHTEDM6sFa7g8O6y6hdynCrC22MLlXQaOB tDYeptVnwErKEqwZlnblSt0gG0Gm5prdhBs9gxtmsRvYNUeZF4nmmBjsTkfG6OLK rkJAUSxtCWa+7PT4Dho2mbzMG8N6Cnz4veaP6cPFdJj78EeryE4vezkCovj+TGvK arNtFAxK4iRxjjzcVuGY07VhP6KwJEqGAmay7VJ7qGM8JvSurd51xRRFZQCNhbfL 8mRnCs1yjPhtoq9SvaxKRLhUrxh1nKB8cISqdhIQ8omMsKMaP3L3rrYDrqWH8Eew KMcB7cvnMcK+Cwl40du/6rTSXgn8jlF6DDA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeguddgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 17 Nov 2023 20:41:05 -0500 (EST) Message-ID: <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> Date: Sat, 18 Nov 2023 03:41:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) 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.9 (---) On 15/11/2023 22:49, Spencer Baugh wrote: > project--list is the new history variable. Using it is mostly trivial; > a small bit of work is necessary in project-prompt-project-name to get > project-names for the history, but that worked out great. Everything > else just seems to work. > > And with savehist-mode enabled, project--list just gets stored > automatically without any code in project.el. > > I can implement a backwards-compatible version if this seems like a > reasonable direction to go in. I haven't tried using it, but there's indeed a lot to like about this patch. What happens if savehist-mode is nil, though? Which it is by default. For users with this setup the project history will just disappear. What kind of backward compatibility did you have in mind? From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: sbaugh@catern.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Nov 2023 15:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: Spencer Baugh , Eli Zaretskii , 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.170032252514998 (code B ref 66993); Sat, 18 Nov 2023 15:49:02 +0000 Received: (at 66993) by debbugs.gnu.org; 18 Nov 2023 15:48:45 +0000 Received: from localhost ([127.0.0.1]:49322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4NYq-0003tn-2d for submit@debbugs.gnu.org; Sat, 18 Nov 2023 10:48:44 -0500 Received: from s.wfbtzhsw.outbound-mail.sendgrid.net ([159.183.224.105]:36772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4NYn-0003sv-2C for 66993@debbugs.gnu.org; Sat, 18 Nov 2023 10:48:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: cc:content-type:from:subject:to; s=s1; bh=RQp8bW4Yw5o8tUKiCETaG/I6Lng1yVPbeVg8+LTjYmM=; b=jjCkL7tFYvQ3I4LdIoHwL9UfHteQ+Xxylk2cZCXnzwVd90tTF0lhgSs+njRLhV7oXKa0 Zx+2/vGzgLE+0VI0AcVvZo5rMRMelTABRqjJ7von+NSfG1xKSYtQ8Ztd/M52mZKKG9q5SA LXOjnWdCXpvow5HNjN1iJnX9cTKKct3eoCRGO/ZXT4aiErL0WjNcCObhv9xlM8RptvriGO 8NqwSBJCvyj7nWbcjCX1o3KvSHo/3C/K3gdpCHDRY5kmeoxbG2aOngmb2rmg4jhl6ZHb3v /QNE1lPLN7uamFbZ0Yxch8y9Nt9ByPbz7kzJJ1Me1fdbEV+spz/BFflFMwlfJr2w== Received: by filterdrecv-b85775b64-8p4fq with SMTP id filterdrecv-b85775b64-8p4fq-1-6558DCD1-9 2023-11-18 15:48:33.148405207 +0000 UTC m=+2754446.778438054 Received: from earth.catern.com (unknown) by geopod-ismtpd-20 (SG) with ESMTP id KaNLh6h6Tra_ifb0J8XDGg Sat, 18 Nov 2023 15:48:32.849 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=74.101.51.129; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gutov.dev Received: from localhost (unknown [74.101.51.129]) by earth.catern.com (Postfix) with ESMTPSA id A18C262DFF; Sat, 18 Nov 2023 15:48:27 +0000 (UTC) From: sbaugh@catern.com In-Reply-To: <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> (Dmitry Gutov's message of "Sat, 18 Nov 2023 03:41:04 +0200") References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> Date: Sat, 18 Nov 2023 15:48:33 +0000 (UTC) Message-ID: <87sf53m59w.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbKRuLH+31s7YlP04u/QQOPdR6tA4bZM2fgLzIwY2HnwRy46hxBCepMdUmzvu7uyA69bF9/rhcRJuZwQWzUZQkHuqv7YSXz65fS+yPfxQqfxgDZznmlmNQOVUw2Irq0h+RfVbHhGq7u+Vey31zuEVNoKpJNiPoCGTRpr5KkaYica5w== X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: multipart/mixed; boundary="=-=-=" 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 (-) --=-=-= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dmitry Gutov writes: > On 15/11/2023 22:49, Spencer Baugh wrote: >> project--list is the new history variable. Using it is mostly trivial; >> a small bit of work is necessary in project-prompt-project-name to get >> project-names for the history, but that worked out great. Everything >> else just seems to work. >> And with savehist-mode enabled, project--list just gets stored >> automatically without any code in project.el. >> I can implement a backwards-compatible version if this seems like a >> reasonable direction to go in. > > I haven't tried using it, but there's indeed a lot to like about this patch. > > What happens if savehist-mode is nil, though? Which it is by > default. For users with this setup the project history will just > disappear. Indeed. > What kind of backward compatibility did you have in mind? I was thinking about either keeping our code for saving to project-list-file around in some obsoleted form, or using a subset of the savehist code to save only project--list when it's not otherwise enabled. But actually, maybe it's time that we just enable savehist by default. I'll try that first - I mailed emacs-devel about it. Then we could delete our project-list-file code once project.el eventually starts requiring Emacs 30. Regardless, how about the below patch which changes the default behavior to only write project-list-file when Emacs exits? I think this is a useful first step no matter what else we do, since it matches the behavior of savehist better. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Only-save-project-list-file-on-exit-by-default.patch >From 1e2ca2abf98f2589db384dc56e68ed4b8e73f1a3 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Sat, 18 Nov 2023 15:43:44 +0000 Subject: [PATCH] Only save project-list-file on exit by default. Saving on most project commands can cause conflicts between Emacs instances. Saving on exit only is more reliable, and it matches the behavior of savehist better, which we might use eventually instead of our own code. To allow opting in to the old behavior, add a new defcustom project-list-file-save defaulting to on-exit. * lisp/progmodes/project.el (project-list-file-save) (project--project-list-changed, project--kill-emacs-hook): Add. (bug#66993) (kill-emacs-hook): Call project--kill-emacs-hook. (project-remember-project, project--remove-from-project-list) (project-remember-projects-under, project-forget-projects-under): Call project--project-list-changed. --- etc/NEWS | 5 +++++ lisp/progmodes/project.el | 45 +++++++++++++++++++++++++++++++-------- 2 files changed, 41 insertions(+), 9 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 8324eb7da1e..bbb27183e96 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1062,6 +1062,11 @@ the current project. The look of the key prompt in the project switcher has been changed slightly. To get the previous one, set this option to 'brackets'. +*** New user option 'project-list-file-save', defaulting to on-exit. +By default, 'project-list-file' is now only saved on exit. To get the +old behavior of saving whenever the project list changed, set this +option to 'on-change' or 'on-change-and-exit'. + *** 'project-try-vc' tries harder to find the responsible VCS. When 'project-vc-extra-root-markers' is non-nil, and causes subdirectory project to be detected which is not a VCS root, we now diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 0855f76aa13..da2cec6abb2 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1713,6 +1713,21 @@ project--ensure-read-project-list (when (eq project--list 'unset) (project--read-project-list))) +(defcustom project-list-file-save 'on-exit + "When to save `project-list-file'. + +If non-nil, the list of known projects is saved in +`project-list-file'. + +If set to `on-change', the list is saved every time it changes. +If set to `on-exit', the list is saved when Emacs exits. If set +to `on-change-and-exit', the list is saved in both cases." + :type '(choice (const :tag "Save on change" on-change) + (const :tag "Save when exiting" on-exit) + (const :tag "Save on change and when exiting" on-change-and-exit)) + :group 'project + :version "30.1") + (defun project--write-project-list () "Save `project--list' in `project-list-file'." (let ((filename project-list-file)) @@ -1728,11 +1743,22 @@ project--write-project-list (current-buffer))) (write-region nil nil filename nil 'silent)))) +(defun project--project-list-changed () + (when (memq project-list-file-save '(on-change on-change-and-exit)) + (project--write-project-list))) + +(defun project--kill-emacs-hook () + (when (memq project-list-file-save '(on-exit on-change-and-exit)) + (project--write-project-list))) + +(add-hook 'kill-emacs-hook #'project--kill-emacs-hook) + ;;;###autoload (defun project-remember-project (pr &optional no-write) "Add project PR to the front of the project list. Save the result in `project-list-file' if the list of projects -has changed, and NO-WRITE is nil." +has changed, `project-list-file-save' is configured to save on +change, and NO-WRITE is nil." (project--ensure-read-project-list) (let ((dir (abbreviate-file-name (project-root pr)))) (unless (equal (caar project--list) dir) @@ -1741,19 +1767,20 @@ project-remember-project (setq project--list (delq ent project--list)))) (push (list dir) project--list) (unless no-write - (project--write-project-list))))) + (project--project-list-changed))))) (defun project--remove-from-project-list (project-root report-message) "Remove directory PROJECT-ROOT of a missing project from the project list. -If the directory was in the list before the removal, save the -result in `project-list-file'. Announce the project's removal -from the list using REPORT-MESSAGE, which is a format string -passed to `message' as its first argument." +If the directory was in the list before the removal and +`project-list-file-save' is configured to save on change, save +the result in `project-list-file'. Announce the project's +removal from the list using REPORT-MESSAGE, which is a format +string passed to `message' as its first argument." (project--ensure-read-project-list) (when-let ((ent (assoc (abbreviate-file-name project-root) project--list))) (setq project--list (delq ent project--list)) (message report-message project-root) - (project--write-project-list))) + (project--project-list-changed))) ;;;###autoload (defun project-forget-project (project-root) @@ -1892,7 +1919,7 @@ project-remember-projects-under (setq count (1+ count)))) (if (zerop count) (message "No projects were found") - (project--write-project-list) + (project--project-list-changed) (message "%d project%s were found" count (if (= count 1) "" "s"))) count)) @@ -1923,7 +1950,7 @@ project-forget-projects-under (setq count (1+ count))))) (if (zerop count) (message "No projects were forgotten") - (project--write-project-list) + (project--project-list-changed) (message "%d project%s were forgotten" count (if (= count 1) "" "s"))) count)) -- 2.42.1 --=-=-=-- From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: sbaugh@catern.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Nov 2023 15:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: Spencer Baugh , Eli Zaretskii , 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.170032301215798 (code B ref 66993); Sat, 18 Nov 2023 15:57:02 +0000 Received: (at 66993) by debbugs.gnu.org; 18 Nov 2023 15:56:52 +0000 Received: from localhost ([127.0.0.1]:49337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4Ngi-00046k-EW for submit@debbugs.gnu.org; Sat, 18 Nov 2023 10:56:52 -0500 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:59582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4Ngg-00046Y-Sh for 66993@debbugs.gnu.org; Sat, 18 Nov 2023 10:56:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=jJZWSGyRVBF1JfUZ2Cvb60bvziOFTkAsfkvBfqWUifk=; b=peJLlZ7iN4p37nw88o3uFnLCai7rqifpJsJ411SuA+2Bih9soEonYne8R6n3botjbkU5 5yc/RbormAWFxCTKn4Jbpg43CT62jlCfFVxSAn+sQCSTsRAOQDTnt/ecSPk7os6QWSzzhp 0Gs5kUbtHB8hjugREk8C+V8CCwH8IQ3qdGHPBiNoXv/UlIcsLATpqESeElhYRQ5/s4q9XX 2a1/mSyFz0SIgxvjxO1R0s01JAkOSWg4VdNZVjSoe6DHbIl2z36OybaLsoXFbouI4XPLRa BfK2KJGq7DyiQSvmjJjJdDbQAnLkYpKBhfx6mq2H/5U3mu54sDCtvZegcGAUDj+A== Received: by filterdrecv-655bd866f5-ttdsl with SMTP id filterdrecv-655bd866f5-ttdsl-1-6558DEBC-9 2023-11-18 15:56:44.269194075 +0000 UTC m=+278137.084017577 Received: from earth.catern.com (unknown) by geopod-ismtpd-15 (SG) with ESMTP id dQbnCwZOTUegtNPwDT-zow Sat, 18 Nov 2023 15:56:44.199 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=74.101.51.129; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gutov.dev Received: from localhost (unknown [74.101.51.129]) by earth.catern.com (Postfix) with ESMTPSA id 7341C62E49; Sat, 18 Nov 2023 15:56:39 +0000 (UTC) From: sbaugh@catern.com In-Reply-To: <87sf53m59w.fsf@catern.com> (sbaugh@catern.com's message of "Sat, 18 Nov 2023 15:48:33 +0000 (UTC)") References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> Date: Sat, 18 Nov 2023 15:56:44 +0000 (UTC) Message-ID: <87o7frm4w8.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbLsBdfJeXNXPtF3oW+mPPc4qKsrrc8DXSIIic56p5n6AcXEv+/6xYWOCwnVdy/BuvNntUj0tN52x1hBTxpQVd+M9b7Y116Ysv1oHSeIOoWjP6Ct9QLsa/+TGLNdwqhYcKS0xH9anin+KQI/zyr0ZO9sRZ4kwH2SWGLUTdocbmIqWA== X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: sbaugh@catern.com writes: > Regardless, how about the below patch which changes the default behavior > to only write project-list-file when Emacs exits? I think this is a > useful first step no matter [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [149.72.123.24 listed in wl.mailspike.net] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record -0.0 T_SCC_BODY_TEXT_LINE No description available. 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 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: 0.2 (/) sbaugh@catern.com writes: > Regardless, how about the below patch which changes the default behavior > to only write project-list-file when Emacs exits? I think this is a > useful first step no matter what else we do, since it matches the > behavior of savehist better. (And plus it actually relates to and fixes this bug - I can take the "use project--list as history" stuff to a different bug later) From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Nov 2023 16:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: sbaugh@catern.com Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org, sbaugh@janestreet.com Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.170032478318904 (code B ref 66993); Sat, 18 Nov 2023 16:27:02 +0000 Received: (at 66993) by debbugs.gnu.org; 18 Nov 2023 16:26:23 +0000 Received: from localhost ([127.0.0.1]:49397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4O9G-0004uq-Vq for submit@debbugs.gnu.org; Sat, 18 Nov 2023 11:26:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4O9C-0004ua-Nu for 66993@debbugs.gnu.org; Sat, 18 Nov 2023 11:26:22 -0500 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 1r4O96-0007nL-BP; Sat, 18 Nov 2023 11:26:12 -0500 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=BVNOhhLRZ/8gEHOnHz36ggvoLrxb0VihHJxAHMTo6QA=; b=Jm4V3r7pGYVh 1ZGyyLZn3CXHSCcqN3TnSgFM7HXA1FkCyOIl1Tzd0fbfVlrGekyLD7nz9BxLz717RB6tzQTqjZTYj EhP2sFulpPXKoELmu/PSp7U1W8Zetlhexwz8bhe6A0be9SAzAI24Dn/GHUjw5IrwQ9zNCdZ9qK43i 9nO1NMOO6GLyH2ikcQJ4P7Vx92e1uNb8m3VZGvz2g9x9DEmYWy3BpMhixYQ83EBB6JhqQTzNr2U0S E66BeATM199sQ6yzT5Gj8UeFxLCBGGWYd/1EBvAX8oUcNJfipqPlAEN51POodLuDOXaXQfsXIldP8 zr1T4mAT9HAlmFRqIakTCQ==; Date: Sat, 18 Nov 2023 18:26:02 +0200 Message-Id: <83a5rbm3j9.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87sf53m59w.fsf@catern.com> (sbaugh@catern.com) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> 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: sbaugh@catern.com > Date: Sat, 18 Nov 2023 15:48:33 +0000 (UTC) > Cc: Spencer Baugh , Eli Zaretskii , > 66993@debbugs.gnu.org > > > What happens if savehist-mode is nil, though? Which it is by > > default. For users with this setup the project history will just > > disappear. > > Indeed. > > > What kind of backward compatibility did you have in mind? > > I was thinking about either keeping our code for saving to > project-list-file around in some obsoleted form, or using a subset of > the savehist code to save only project--list when it's not otherwise > enabled. > > But actually, maybe it's time that we just enable savehist by default. Even if we decide to do that (and I'm not at all sure we should), how would that solve the difficulty pointed out by Dmitry? Even if savehist is ON by default, the user could turn it OFF, right? From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Nov 2023 23:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org, sbaugh@janestreet.com Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.170034905429620 (code B ref 66993); Sat, 18 Nov 2023 23:11:02 +0000 Received: (at 66993) by debbugs.gnu.org; 18 Nov 2023 23:10:54 +0000 Received: from localhost ([127.0.0.1]:49646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4USj-0007hf-Oe for submit@debbugs.gnu.org; Sat, 18 Nov 2023 18:10:54 -0500 Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:20848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4USg-0007hR-NA for 66993@debbugs.gnu.org; Sat, 18 Nov 2023 18:10:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=Ih0NSYNOfuPVeq69D+6YtzAUzKrCgb7Yd9QvmiXu6cA=; b=i/caCUbydwqu8gHOblJiq3/JV4a9AxwUI49IRYDInMwPUC+sZ8fwQPsDgUoAkj6Xacng 9WDub9OlapzhfFa3dBibOya1Pfxo8wjgzezohN6wTDmxh+ZL5wp+1brOziHQM9nay91qdb DPu06gPYszZzkVj1o8OpuSw/79hbgQS/7ToIDIcMvVOqwl4ga7sW7NLkFsz/UKq2wOzDKb WLEVoX0ljftxkZ+L3Mcd1M3fpY1xhIB7CHDMrLJE/V11uY2QFnyXabbct64MqbsGsX6FPa FmjQB/qEWIOHqayH47CMeaA+2BDS/t46cdR3FMr6P/s1xpTuoZTcPKXNpA+YBnyg== Received: by filterdrecv-d585b8d85-jxswg with SMTP id filterdrecv-d585b8d85-jxswg-1-65594473-C 2023-11-18 23:10:43.658315671 +0000 UTC m=+2781053.668716329 Received: from earth.catern.com (unknown) by geopod-ismtpd-39 (SG) with ESMTP id pZuAfPzFSui4FjPecZXOAA Sat, 18 Nov 2023 23:10:43.376 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=74.101.51.129; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Received: from localhost (unknown [74.101.51.129]) by earth.catern.com (Postfix) with ESMTPSA id 1825D62EB4; Sat, 18 Nov 2023 23:10:36 +0000 (UTC) From: Spencer Baugh In-Reply-To: <83a5rbm3j9.fsf@gnu.org> References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> <83a5rbm3j9.fsf@gnu.org> Date: Sat, 18 Nov 2023 23:10:43 +0000 (UTC) Message-ID: <87cyw6mzdf.fsf@catern.com> MIME-Version: 1.0 X-SG-EID: GW3oCMoYnalRiojMOuLzE6x2H5kORXvlCdz1UwQVRMVT4fbh9ODEfCogOe74cOrI4e0V+MFZgakz9Re5a6/CgkrgiEN2hz+QMnHLCf2x/+gfV4RINa4vl0SyqEIHY0QnHc/6Epcgfu+i1qaDclnN8FUnRNbL4tJ8RCFPfXE9uDtxAIHbY/N2bPP5ZHc8aQLKSiI5yNRRIA9MsC0uCmadUrDryMvWq9vjv7st8c07nw/86UQaHmermxIUnWnyhenN X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Sat, 18 Nov 2023 15:48:33 +0000 (UTC) >> Cc: Spencer Baugh , Eli Zaretskii , >> 66993@debb [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [149.72.154.232 listed in wl.mailspike.net] 1.3 RCVD_IN_VALIDITY_RPBL RBL: Relay in Validity RPBL, https://senderscore.org/blocklistlookup/ [149.72.154.232 listed in bl.score.senderscore.com] -0.0 T_SCC_BODY_TEXT_LINE No description available. 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 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.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Sat, 18 Nov 2023 15:48:33 +0000 (UTC) >> Cc: Spencer Baugh , Eli Zaretskii , >> 66993@debb [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [149.72.154.232 listed in wl.mailspike.net] 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] 1.3 RCVD_IN_VALIDITY_RPBL RBL: Relay in Validity RPBL, https://senderscore.org/blocklistlookup/ [149.72.154.232 listed in bl.score.senderscore.com] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record -0.0 T_SCC_BODY_TEXT_LINE No description available. 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Sat, 18 Nov 2023 15:48:33 +0000 (UTC) >> Cc: Spencer Baugh , Eli Zaretskii , >> 66993@debbugs.gnu.org >> >> > What happens if savehist-mode is nil, though? Which it is by >> > default. For users with this setup the project history will just >> > disappear. >> >> Indeed. >> >> > What kind of backward compatibility did you have in mind? >> >> I was thinking about either keeping our code for saving to >> project-list-file around in some obsoleted form, or using a subset of >> the savehist code to save only project--list when it's not otherwise >> enabled. >> >> But actually, maybe it's time that we just enable savehist by default. > > Even if we decide to do that (and I'm not at all sure we should), how > would that solve the difficulty pointed out by Dmitry? Even if > savehist is ON by default, the user could turn it OFF, right? That's fine, we'd still be preserving backwards-compatibility: project--list would still be saved by default. The user could turn it off, if they want, but that's not a problem - they can turn it off if they want. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2023 06:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org, sbaugh@janestreet.com Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.17003739447823 (code B ref 66993); Sun, 19 Nov 2023 06:06:02 +0000 Received: (at 66993) by debbugs.gnu.org; 19 Nov 2023 06:05:44 +0000 Received: from localhost ([127.0.0.1]:49783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4awC-000227-9d for submit@debbugs.gnu.org; Sun, 19 Nov 2023 01:05:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4aw7-00021m-N3 for 66993@debbugs.gnu.org; Sun, 19 Nov 2023 01:05:42 -0500 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 1r4aw0-00014u-OG; Sun, 19 Nov 2023 01:05:32 -0500 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=HDjvks1UZtJxuU1unAA6i+svGNyyqcCM/nkR73q0LNg=; b=I6//6+Msrf+X LBEUyyyKPOuGosVpk8XMaovKjg0d7WJMq2XKqYjl7ERzGx/ZThGVYasJnDZl9qbxgwqFmd90srN6U Q0NdSoP/uV9Dua9azztQ8Qq7bnB7aAyiLRyBQBE7BaznQQr/URXhRreHhe61g6dMjr5+MoeokwoS+ fR3a2n6YHj7FVbyZAblfkGbPPy5DXxCtU08xEiu2zkKpHJK3riI+bMMeh0qTw/tuoYEVcgg1G6CBS DKOUsX1aldxZPRmB5X+M7yg6byyKxrPy1JbmBoevYWwYd4ILd433ZMbbJn4V3ts3i43oZutaEXMbB RvNmq/a+aNciYdsH0JyPRA==; Date: Sun, 19 Nov 2023 08:05:14 +0200 Message-Id: <83ttpil1lx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87cyw6mzdf.fsf@catern.com> (message from Spencer Baugh on Sat, 18 Nov 2023 23:10:43 +0000 (UTC)) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> <83a5rbm3j9.fsf@gnu.org> <87cyw6mzdf.fsf@catern.com> 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: Sat, 18 Nov 2023 23:10:43 +0000 (UTC) > Cc: dmitry@gutov.dev, sbaugh@janestreet.com, 66993@debbugs.gnu.org > > Eli Zaretskii writes: > >> But actually, maybe it's time that we just enable savehist by default. > > > > Even if we decide to do that (and I'm not at all sure we should), how > > would that solve the difficulty pointed out by Dmitry? Even if > > savehist is ON by default, the user could turn it OFF, right? > > That's fine, we'd still be preserving backwards-compatibility: > project--list would still be saved by default. The user could turn it > off, if they want, but that's not a problem - they can turn it off if > they want. IMNSHO, it is a very bad idea to have one feature turn on and off as a side effect of another, unrelated feature. We should not have such inelegant dependencies. savehist is a general-purpose feature which saves the history of important user actions, whereas the history of projects is a completely different feature from a much more narrow area of user activities. They should not depend on one another, not directly anyway. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2023 14:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii , sbaugh@catern.com Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.170040429630649 (code B ref 66993); Sun, 19 Nov 2023 14:32:01 +0000 Received: (at 66993) by debbugs.gnu.org; 19 Nov 2023 14:31:36 +0000 Received: from localhost ([127.0.0.1]:50239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4ipj-0007yH-Ns for submit@debbugs.gnu.org; Sun, 19 Nov 2023 09:31:36 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:60331) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4iph-0007y3-64 for 66993@debbugs.gnu.org; Sun, 19 Nov 2023 09:31:34 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7035E5C020F; Sun, 19 Nov 2023 09:31:26 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 19 Nov 2023 09:31:26 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1700404286; x=1700490686; bh=QN/6uqUSU0zIgC8iMDOU38+nk7tQ7DPgsCI hX20eHf0=; b=oyXA5uL11SyCJTh8ujXGNXwu6zE0ispPFimuj73zMmbPfctJKmv eWj7CiF0xv2YOX3RAbrBA2dd2mgJ9Watey4p2xDi1jufiBSkhju5JSMmGlHLmoLR 95tiAmPyi9fre+VM4yDuHXbPjwS1RboLoRbu1NhSyQJUsAUTcP24ENozoZb2G7lv 8kR4ol6O9GhNMjBtFp6zaAgYpaFgT6HbLxq0aVMix3ExkKXbDmkWuDOKt5hEBoNR yjgkJHqyhO3LPMJvLmb5Dm1mlSlJTAYnuMbun5n9udGFOmdaD7swOY3jkrbsOYUV RQNu/y+bVEJOkCZcAVLi3eBZFFLMnC7t/zQ== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700404286; x=1700490686; bh=QN/6uqUSU0zIgC8iMDOU38+nk7tQ7DPgsCI hX20eHf0=; b=KL5MMb0YcOva+f55ex6l6Hnd8jbg1TWoc0MQzggNz8ihfNdCwNR puPE4HLLOTl7RpayuKft/9Rf078wwAbfJJkbKeEWwZNzH32/dabcg0dDWPCETi0k 1J3NWb7HulJ3vadRHxhLVoa2BD5HvhOJvvE+VB0Nf3gJNtqxnoNQ+AtyG0Mp5/TK dbvfpX4vB9+a6I6RxEn1DIWQOK8ykkoAbA4D8PXeoZRCEhq3+5tC9Rs2jB2WL+9o gPpja24VnWYTMWPgt5eYLNCg2Xu6pf0gxekDwphWrWcJVFX0WDIfIbLzfjibQfW3 XCz0cF9JCO/s+8DiDflBBjutHmHnq+in6fg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeggedgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 19 Nov 2023 09:31:24 -0500 (EST) Message-ID: <3bad2052-286b-8532-b9ae-72e8278d5ff3@gutov.dev> Date: Sun, 19 Nov 2023 16:31:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> <83a5rbm3j9.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83a5rbm3j9.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) 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.9 (---) On 18/11/2023 18:26, Eli Zaretskii wrote: >> From:sbaugh@catern.com >> Date: Sat, 18 Nov 2023 15:48:33 +0000 (UTC) >> Cc: Spencer Baugh, Eli Zaretskii, >> 66993@debbugs.gnu.org >> >>> What happens if savehist-mode is nil, though? Which it is by >>> default. For users with this setup the project history will just >>> disappear. >> Indeed. >> >>> What kind of backward compatibility did you have in mind? >> I was thinking about either keeping our code for saving to >> project-list-file around in some obsoleted form, or using a subset of >> the savehist code to save only project--list when it's not otherwise >> enabled. >> >> But actually, maybe it's time that we just enable savehist by default. > Even if we decide to do that (and I'm not at all sure we should), how > would that solve the difficulty pointed out by Dmitry? Even if > savehist is ON by default, the user could turn it OFF, right? I think the working hypothesis is that they are the same feature: if project--list is used for saving the previous inputs, it can be covered by savehist-mode. And if used explicitly turns off savehist-mode (after it's been made the default), that can mean they're fine with not storing all of those histories, including the projects one. AFAIK project-known-project-roots is also used by some "splash page" packages to list the known projects for quick visiting, but that's not very different from using file-name-history to show a list of "last visited files", which also some code does. So I was primarily worried about migration -- for those who didn't enable savehist-mode yet (perhaps due to not being aware of it), but have existing saved project histories. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2023 14:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: sbaugh@catern.com Cc: Spencer Baugh , Eli Zaretskii , 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.170040445330874 (code B ref 66993); Sun, 19 Nov 2023 14:35:02 +0000 Received: (at 66993) by debbugs.gnu.org; 19 Nov 2023 14:34:13 +0000 Received: from localhost ([127.0.0.1]:50244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4isH-00081t-A3 for submit@debbugs.gnu.org; Sun, 19 Nov 2023 09:34:13 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:39867) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4isF-00081f-Cq for 66993@debbugs.gnu.org; Sun, 19 Nov 2023 09:34:12 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id BF5C45C003E; Sun, 19 Nov 2023 09:34:04 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 19 Nov 2023 09:34:04 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1700404444; x=1700490844; bh=0jFfdSmchOaOgMfy6LOOVzRQLl1USKhPvER VQXt2/oU=; b=b1YK/aRBET3aowr1t53ehkTT9qBzJNRKQNjQtozFeZyPpWuwG9v bzGNvsCYE7HKdwG+o/hKTHzeblLrkvWOu6sa0AFA4ioSVj8Z3Aa6wQRqN0b3G2Un FIkeIZr8esO41xZTXyg2odA0Bh72zH4uiQw6S+9UqpAirxHSL1HEStlb+hPAN+hU BRff+1SoEboZX3UNnR8FMPjKKes0CmrbnS8WALLeUUFY4f9hDVSiVHPANs4OGUSn 7fUSo1YmNR2kDSQ9nWi7qrdbH050vJWfRpo64VhcHQIJPTePGTi1bJEfpno0vkfB 1u/fjPlSq7oVgVY/A3AxQ5Dxe4RNeIpek2g== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700404444; x=1700490844; bh=0jFfdSmchOaOgMfy6LOOVzRQLl1USKhPvER VQXt2/oU=; b=M9YfMEfI7YQZf2L8GKv6Ov2hXXw6/G817ikfICgW5fgzj2RxkyD LuLtoDIjzmJL4ao7z0Rv0QGiCRaJem7Qf2kUpQK03MsmM+ofC0IwnCTJmciyZgTC JSbQ0rB39d3SNCtshhYtBtRqol83wPKfwigQHrjy/3AadeGDQBzTD3Pj2VBMxuP1 4RbgzmqtdPJTXrzNqXOku0yCAlcwb2U/RJQe67SMu/DMKtyrdURsieEZRwsVwlhs v3EhzVPTcVSbJCPmssWtOCfUg20z1oiMa4UnDWybS1jayHEIlBAKHHakDPo2lGLr jMHlJl8iy6AhnuFcvq/Ef730OizbA8JPkUQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeggedgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 19 Nov 2023 09:34:01 -0500 (EST) Message-ID: <76f46ffc-ece6-8c9b-02f9-a85ce96d30f1@gutov.dev> Date: Sun, 19 Nov 2023 16:33:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> From: Dmitry Gutov In-Reply-To: <87sf53m59w.fsf@catern.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) 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.9 (---) On 18/11/2023 17:48, sbaugh@catern.com wrote: > +(defcustom project-list-file-save 'on-exit > + "When to save `project-list-file'. > + > +If non-nil, the list of known projects is saved in > +`project-list-file'. > + > +If set to `on-change', the list is saved every time it changes. > +If set to `on-exit', the list is saved when Emacs exits. If set > +to `on-change-and-exit', the list is saved in both cases." > + :type '(choice (const :tag "Save on change" on-change) > + (const :tag "Save when exiting" on-exit) > + (const :tag "Save on change and when exiting" on-change-and-exit)) > + :group 'project > + :version "30.1") I think I'd rather we change the behavior to straight away save on exit, no customization needed. For most users the observable behavior will be the same, but we won't have to keep supporting the 'on-change' value later if/when we migrate to use savehist-mode instead. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2023 14:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org, sbaugh@janestreet.com Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.1700405681658 (code B ref 66993); Sun, 19 Nov 2023 14:55:02 +0000 Received: (at 66993) by debbugs.gnu.org; 19 Nov 2023 14:54:41 +0000 Received: from localhost ([127.0.0.1]:50249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4jC4-0000AY-FT for submit@debbugs.gnu.org; Sun, 19 Nov 2023 09:54:40 -0500 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:56344) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4jBy-0000AG-N2 for 66993@debbugs.gnu.org; Sun, 19 Nov 2023 09:54:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=ULsMCkujmWi6y/WfL57IXOZRPK2vLaks+bp3WBHLSsQ=; b=ZTlC5ELRsO9/7o0lsGSK1s8qUEzuHBIGpA/b8BhhZdlOxLKiPP0tKrc2tS1Oh+ms/GPZ ZR8Awx4AjjQkoNK2T1cBbxtkyjKgiFKhzDcEPUq7DVXMNGkf/Am403QyZBuR4VbEfCiJ32 yto4DYFG/0j6llSNIQFgKtKK+P0OBolgfTrXJd0OjERc0QskBCyFeqdrc/G6RI53yLAd9u AW2avNayl29nTFFugJTZrhbpqfj0qXq7v+OBqiVFlPjgL/wqnZOeJtvvwqJXOC4NSTL9AJ Li5aBRGEacv66wbAShAL5Ohi5rD4BdGmtteeZtYFejkphYsZg7bdOQHMR1I7GKVg== Received: by filterdrecv-d585b8d85-kx4qj with SMTP id filterdrecv-d585b8d85-kx4qj-1-655A21A3-8 2023-11-19 14:54:27.310950541 +0000 UTC m=+2837654.355768954 Received: from earth.catern.com (unknown) by geopod-ismtpd-6 (SG) with ESMTP id gA0WEvcvSKmM3fbN1VXM0w Sun, 19 Nov 2023 14:54:27.081 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=74.101.51.129; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Received: from localhost (unknown [74.101.51.129]) by earth.catern.com (Postfix) with ESMTPSA id 1146A62E3C; Sun, 19 Nov 2023 14:54:18 +0000 (UTC) From: Spencer Baugh In-Reply-To: <83ttpil1lx.fsf@gnu.org> References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> <83a5rbm3j9.fsf@gnu.org> <87cyw6mzdf.fsf@catern.com> <83ttpil1lx.fsf@gnu.org> Date: Sun, 19 Nov 2023 14:54:27 +0000 (UTC) Message-ID: <8734x1n691.fsf@catern.com> MIME-Version: 1.0 X-SG-EID: GW3oCMoYnalRiojMOuLzE6x2H5kORXvlCdz1UwQVRMVT4fbh9ODEfCogOe74cOrI4e0V+MFZgakz9Re5a6/Cgg0QZ8UizsfdGOkYV8VgClZMg7gzHR9i2VLIgpcgvoLdrumheiOUfoN91L3XSBMyD8keMfgdNYv0tiLqKuuyQTZZynob43eOV6HO8oJChTNJBsKAhECPDQjsg+fcE4iRVRpIJGeoExdR9obisFEiW+hAjIN3KYlus3mh5yPTsqza X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 0.2 (/) Eli Zaretskii writes: >> From: Spencer Baugh >> Date: Sat, 18 Nov 2023 23:10:43 +0000 (UTC) >> Cc: dmitry@gutov.dev, sbaugh@janestreet.com, 66993@debbugs.gnu.org >> >> Eli Zaretskii writes: >> >> But actually, maybe it's time that we just enable savehist by default. >> > >> > Even if we decide to do that (and I'm not at all sure we should), how >> > would that solve the difficulty pointed out by Dmitry? Even if >> > savehist is ON by default, the user could turn it OFF, right? >> >> That's fine, we'd still be preserving backwards-compatibility: >> project--list would still be saved by default. The user could turn it >> off, if they want, but that's not a problem - they can turn it off if >> they want. > > IMNSHO, it is a very bad idea to have one feature turn on and off as a > side effect of another, unrelated feature. We should not have such > inelegant dependencies. savehist is a general-purpose feature which > saves the history of important user actions, whereas the history of > projects is a completely different feature from a much more narrow > area of user activities. They should not depend on one another, not > directly anyway. project-prompt-project-dir minibuffer history is is in fact the same feature as (for example) read-file-name minibuffer history, we just didn't realize it before and so we unnecessarily implemented separate logic for persisting it. If savehist had been on by default when project.el was added, there would have been no need for the separate logic. So it makes sense for them to be unified. (They can still be turned off independently with savehist configuration, of course, if the user wants to) From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2023 15:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@catern.com, 66993@debbugs.gnu.org, sbaugh@janestreet.com Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.17004074335088 (code B ref 66993); Sun, 19 Nov 2023 15:24:02 +0000 Received: (at 66993) by debbugs.gnu.org; 19 Nov 2023 15:23:53 +0000 Received: from localhost ([127.0.0.1]:51932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4jeK-0001K0-Nn for submit@debbugs.gnu.org; Sun, 19 Nov 2023 10:23:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:32816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4jeG-0001Jk-Fu for 66993@debbugs.gnu.org; Sun, 19 Nov 2023 10:23:51 -0500 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 1r4je8-0007z2-VR; Sun, 19 Nov 2023 10:23:40 -0500 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=Cyk0HNLcoyKNEwBM05O2e/Ai0lSt7mby92UHPepQKDM=; b=CfK0w8ohfcVZ MkocHAvXt7RC6IxBEBrrh8rIFJaLJgoCwuWt99KeldEjSarV4EdTz+WmR43IigrJAHLXHXL5GcLgS 6uM9WYvdU5sUfG5jjIID72F+Riisxm0Q/MN3zOlgEbN9Huk+rYTZ6OnxDgromfMy08nyuMMZdgkrZ EGYfwSuTPpTtFGHNxFxfMzA3p/yZx9D/fHVi1JN1GxNJZpIcH7rdLGvi2vzMYH9XlJkKvoN3L/Ngl RObSz8+6Tc5PmJxgV7yTo1EVG6CuB6+D2ApiNevkE9/yTYCfnbllW2WVFmYIVCAl3ZQ43iR0S4Q3x udTR6UngH4/lfb43T83djg==; Date: Sun, 19 Nov 2023 17:23:22 +0200 Message-Id: <83jzqdkbrp.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <3bad2052-286b-8532-b9ae-72e8278d5ff3@gutov.dev> (message from Dmitry Gutov on Sun, 19 Nov 2023 16:31:22 +0200) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> <83a5rbm3j9.fsf@gnu.org> <3bad2052-286b-8532-b9ae-72e8278d5ff3@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: Sun, 19 Nov 2023 16:31:22 +0200 > Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org > From: Dmitry Gutov > > On 18/11/2023 18:26, Eli Zaretskii wrote: > > Even if we decide to do that (and I'm not at all sure we should), how > > would that solve the difficulty pointed out by Dmitry? Even if > > savehist is ON by default, the user could turn it OFF, right? > > I think the working hypothesis is that they are the same feature: if > project--list is used for saving the previous inputs, it can be covered > by savehist-mode. Then maybe I'm missing something: savehist is AFAIU a feature that saves minibuffer history, not just _any_ history. Are we talking about minibuffer history here? I didn't think so. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2023 18:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: sbaugh@catern.com Cc: Dmitry Gutov , Eli Zaretskii , 66993@debbugs.gnu.org, Spencer Baugh Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.170041727020939 (code B ref 66993); Sun, 19 Nov 2023 18:08:02 +0000 Received: (at 66993) by debbugs.gnu.org; 19 Nov 2023 18:07:50 +0000 Received: from localhost ([127.0.0.1]:52056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4mCz-0005Rf-QJ for submit@debbugs.gnu.org; Sun, 19 Nov 2023 13:07:50 -0500 Received: from relay6-d.mail.gandi.net ([2001:4b98:dc4:8::226]:35959) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4mCx-0005RQ-PE for 66993@debbugs.gnu.org; Sun, 19 Nov 2023 13:07:48 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id 4C500C0002; Sun, 19 Nov 2023 18:07:37 +0000 (UTC) From: Juri Linkov In-Reply-To: <87sf53m59w.fsf@catern.com> (sbaugh@catern.com's message of "Sat, 18 Nov 2023 15:48:33 +0000 (UTC)") Organization: LINKOV.NET References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> Date: Sun, 19 Nov 2023 19:52:31 +0200 Message-ID: <86edglu22w.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net 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 (-) > But actually, maybe it's time that we just enable savehist by default. Have you considered using define-multisession-variable? What are pros and cons? From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2023 19:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Juri Linkov Cc: Dmitry Gutov , Eli Zaretskii , 66993@debbugs.gnu.org, Spencer Baugh Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.17004227167271 (code B ref 66993); Sun, 19 Nov 2023 19:39:01 +0000 Received: (at 66993) by debbugs.gnu.org; 19 Nov 2023 19:38:36 +0000 Received: from localhost ([127.0.0.1]:52124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4ncp-0001tD-Us for submit@debbugs.gnu.org; Sun, 19 Nov 2023 14:38:36 -0500 Received: from s.wfbtzhsv.outbound-mail.sendgrid.net ([159.183.224.104]:1580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4nco-0001sx-0E for 66993@debbugs.gnu.org; Sun, 19 Nov 2023 14:38:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=JtUAYqbOBzxTnirHPCxxGk6Iwu+6VtTu9LE+ieYuxyk=; b=o8rrjRCOPQ2ncyXbPMWtwFCwcJ5tajJpd/q/eWJW2li6rOGSKIEER6O5Yy7svIsnFrq6 SQJtUuG6Tr5RUKu1ABnqqNoQg7gCUjkUQB9q9rHPHkvS0bkYzzTZ+BtnM0JGM83GfI4PCR 3Eu+HestQg2rmT9/Pw7U/R1lFruKQ6N0XjB72M/OZAI+Gpy4YcRXtuCebbmyiBgSX8rfVP ZpZSBFHrcCkn5mtFyV8Kvw5FOx0uqZS28GRxxt1lKfALfIA6OhnB+ATAopRyCxghhpdsLs Vz6HGB//lT5ZRUSCLJNQZHUCQAdyCR2B2xGWe3JB0hIbgc1c+oWt9KZhNZsCUVeg== Received: by filterdrecv-5bbdbb56cd-w94vd with SMTP id filterdrecv-5bbdbb56cd-w94vd-1-655A6431-11 2023-11-19 19:38:25.768030608 +0000 UTC m=+2854710.035284171 Received: from earth.catern.com (unknown) by geopod-ismtpd-16 (SG) with ESMTP id -nr46UsdT5m7NSWi19nkWg Sun, 19 Nov 2023 19:38:25.701 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=74.101.51.129; helo=localhost; envelope-from=sbaugh@catern.com; receiver=linkov.net Received: from localhost (unknown [74.101.51.129]) by earth.catern.com (Postfix) with ESMTPSA id B8CEE62E3C; Sun, 19 Nov 2023 19:38:16 +0000 (UTC) From: Spencer Baugh In-Reply-To: <86edglu22w.fsf@mail.linkov.net> References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> <86edglu22w.fsf@mail.linkov.net> Date: Sun, 19 Nov 2023 19:38:25 +0000 (UTC) Message-ID: <87edgllejb.fsf@catern.com> MIME-Version: 1.0 X-SG-EID: GW3oCMoYnalRiojMOuLzE6x2H5kORXvlCdz1UwQVRMVT4fbh9ODEfCogOe74cOrI4e0V+MFZgakz9Re5a6/Cggmf3ZdTlNXTVDPAIC75G7YryO8edo2JHA/IFzojfJeFz4VRaTkwMa49iLMdARgk+fn71+EYMg794494KNh21ix9PklYWRTHNzgDElrW/zWEsOmZdEPmThO4WuWxFzB79bTbZ7kaUf6l9nhzKQjJvu4YMm5mwor1EfIY0MlsP7Xo X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 (-) Juri Linkov writes: >> But actually, maybe it's time that we just enable savehist by default. > > Have you considered using define-multisession-variable? > What are pros and cons? That seems like a good idea too. I'll try putting together a patch which uses define-multisession-variable for project--list. If project--list becomes a minibuffer history variable and also is a multisession variable, though, perhaps savehist-mode would interact poorly. (Then again, maybe instead of enabling savehist mode by default, we should just define-multisession-variable file-name-history?) From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Nov 2023 01:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh , Juri Linkov Cc: Spencer Baugh , Eli Zaretskii , 66993@debbugs.gnu.org Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.170044320219632 (code B ref 66993); Mon, 20 Nov 2023 01:21:02 +0000 Received: (at 66993) by debbugs.gnu.org; 20 Nov 2023 01:20:02 +0000 Received: from localhost ([127.0.0.1]:52293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4sxG-00056O-6O for submit@debbugs.gnu.org; Sun, 19 Nov 2023 20:20:02 -0500 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:44939) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4sxD-00055y-Vt for 66993@debbugs.gnu.org; Sun, 19 Nov 2023 20:20:01 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id ED5DD3200971; Sun, 19 Nov 2023 20:19:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 19 Nov 2023 20:19:52 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1700443191; x=1700529591; bh=KsFaOV7xTBeALUeCl7VMu6Aza0jj40rilcL A+h69Zko=; b=MFSZq3YKlLU7Flo+eyhASxUPAqHIDa18c4JR8N2Tn6SWW6z0Gjf zaKLiARnwf+uLBUzz5j32EuUko5KS+VkM2EAPm0Wz5Zw6RLYjjQURmOG/Z976JIB +YygD6GuOBeBUfuCMc82XkedQuug8D7gMfg1WrRh++46eAc+Gqzv8sr3PQfHPE4X QDZKch+cQqbPyPhq2vcRZ2bCorKr0yZaPpM0vmMW/xpLcQj5xQ8Gmqpnw/wuf7Z2 g9AnMFUglbNwKs7z4sHzL6ktI/Veq1IM3UwJphOyP3RsezHn4n/usiVTrReQdoh1 sUtSwW6k+2vrKk04tpu0PlWHrcV/+LxLeGg== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700443191; x=1700529591; bh=KsFaOV7xTBeALUeCl7VMu6Aza0jj40rilcL A+h69Zko=; b=XCLIJ7Ts/owoylFOxQyy9m3afBW7BJLAKFoPdbtzmYuUQc5H+af MI8it4Q/WQERmYU+zJnlc43uLm3ogfw3xxflkR6wtNxhjhq5de4o+omWTGrg78cY BhpfL7jyt0kP/civnUvQj3eVpcYKtXtcNHmC5VFEguqDp4YMsfOgoUZRQKuWLgNk HAJEznZVgy0U/Jykr91vSZmaLAOD7MMXBaT66kL6y2vnl3FRt5lMkkYVNlNqY9x4 0hgmR2xglfBNfVV9CXH/84b+UrfaCfakfrGnNHoqb3eQv0Jr2iG31vQRpS3Q6d95 q5OcHZBRT+IwrAnzZgPeSedCbPqUtZR8eoQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeghedgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 19 Nov 2023 20:19:49 -0500 (EST) Message-ID: <9310604c-e804-eef6-435e-6aba92df9e39@gutov.dev> Date: Mon, 20 Nov 2023 03:19:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> <86edglu22w.fsf@mail.linkov.net> <87edgllejb.fsf@catern.com> From: Dmitry Gutov In-Reply-To: <87edgllejb.fsf@catern.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) 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.9 (---) On 19/11/2023 21:38, Spencer Baugh wrote: > If project--list becomes a minibuffer history variable and also is a > multisession variable, though, perhaps savehist-mode would interact > poorly. I guess that, ultimately, it should be one or the other. Or neither. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Nov 2023 02:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: sbaugh@catern.com, 66993@debbugs.gnu.org, sbaugh@janestreet.com Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.170044597424653 (code B ref 66993); Mon, 20 Nov 2023 02:07:01 +0000 Received: (at 66993) by debbugs.gnu.org; 20 Nov 2023 02:06:14 +0000 Received: from localhost ([127.0.0.1]:52304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4tfx-0006PY-VT for submit@debbugs.gnu.org; Sun, 19 Nov 2023 21:06:14 -0500 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:58109) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4tfu-0006PB-F0 for 66993@debbugs.gnu.org; Sun, 19 Nov 2023 21:06:13 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id C412C320077A; Sun, 19 Nov 2023 21:06:01 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 19 Nov 2023 21:06:02 -0500 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:sender:subject:subject:to:to; s=fm2; t= 1700445961; x=1700532361; bh=fVZbEw4xFUvIWgifXd9ITB5v/Y8WJ8+Or2x CpuF4xmo=; b=XAwB1wnb0QziC+wUIB+XDhi29S+1YQAOvjsIksa4tv/D5ld83oc IOy9A37uM/xGMxy2bTt3xuEvJioqLxaa4SuiL1g8rg4NSHhqJTnH8m48dRbYw8wA uytKNXBpDViDsLS09wXh5Lm4mu7k7fVMLsXu9ysvDv9wbTDes30/5BNtrPlcumyo Zk/pEbEIFfD17Sp44+xI3nwrA4pPkceVrbuVCsux5FkwV7dnbNRDZO8SqsuZthuc i9gfUMZJioW/G8IY4LeTUhWdugSFL09aWVHWxpKQK6ZNtCY2Q6qvojW5dFV4waDy Iow2IaXNck9vBkv8Kb8EHZ7YAVdNEXbt0Aw== 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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700445961; x=1700532361; bh=fVZbEw4xFUvIWgifXd9ITB5v/Y8WJ8+Or2x CpuF4xmo=; b=0G8cwHFMNoHhbUvLEeHNRm5vU6mBt7mtt8WgLTEy1spzcsCsriS CHm1qTtfKOtLCsrlmgVRmEZ84MCkG47dnAs+6Ds9B4uF5bhPGNqgNuGeLePIGAS2 kvaFp1kOMnCYedryMV8oafFUcmRglIqM02kRU/sR/YfnvPn28ACgH4PXgNhYxugq LBHPSfbdzgkBcULKcO3c1OzQf+DoxbN9J6EeXWREnjfmwE18j7MkAK2qpDhYhb5H CHD5LDXBKVcJ/Nl0PdWYnSZQrJZmeABskHp8LLKtl9VCMKcDSkzFudnJdODc0kvw 2tw8r+2Rsdbl81boQY1SoT7ATL3KRgTTzpQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeghedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 19 Nov 2023 21:05:59 -0500 (EST) Message-ID: <7d493257-04ab-8325-03af-d9c65236da7a@gutov.dev> Date: Mon, 20 Nov 2023 04:05:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> <83a5rbm3j9.fsf@gnu.org> <3bad2052-286b-8532-b9ae-72e8278d5ff3@gutov.dev> <83jzqdkbrp.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83jzqdkbrp.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) 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.9 (---) On 19/11/2023 17:23, Eli Zaretskii wrote: >> Date: Sun, 19 Nov 2023 16:31:22 +0200 >> Cc:sbaugh@janestreet.com,66993@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 18/11/2023 18:26, Eli Zaretskii wrote: >>> Even if we decide to do that (and I'm not at all sure we should), how >>> would that solve the difficulty pointed out by Dmitry? Even if >>> savehist is ON by default, the user could turn it OFF, right? >> I think the working hypothesis is that they are the same feature: if >> project--list is used for saving the previous inputs, it can be covered >> by savehist-mode. > Then maybe I'm missing something: savehist is AFAIU a feature that > saves minibuffer history, not just_any_ history. Perhaps it would be accurate to say that it saves minibuffer histories by default, but it can also save other history variables when 'savehist-additional-variables' is customized. > Are we talking > about minibuffer history here? I didn't think so. Let me try to list the similarities and differences. Similar: - The contents of project--list come from interactions with the user. They're always a result of the user invoking a command. Sometimes the user will input the project's directory manually in the minibuffer, though in many/most cases that addition will be determined automatically by our code (and yet would still be added to the "project history" in project--list, because that looks like the most helpful approach for this list). - The contents of project--list are, like file-name-history, used during completion when the user is asked to choose the project (when it couldn't be or wouldn't be selected automatically). Different: - When writing project--list to disk, we eliminate duplicate entries, both consecutive and distant ones. Again, seems more useful here. - When file-name-history is used, something else is used as the completion table. Whereas project--list *is* the completion table. Whether it should be (in certain order) also used in the input history, is perhaps a potential future improvement. So I don't know if project--list is a "minibuffer history", but depending on the POV one might decide it's close enough. From unknown Thu Sep 11 09:17:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Nov 2023 11:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@catern.com, 66993@debbugs.gnu.org, sbaugh@janestreet.com Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.170048149317790 (code B ref 66993); Mon, 20 Nov 2023 11:59:01 +0000 Received: (at 66993) by debbugs.gnu.org; 20 Nov 2023 11:58:13 +0000 Received: from localhost ([127.0.0.1]:52646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r52uq-0004cs-Rj for submit@debbugs.gnu.org; Mon, 20 Nov 2023 06:58:13 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55614) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r52uo-0004cf-46 for 66993@debbugs.gnu.org; Mon, 20 Nov 2023 06:58:10 -0500 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 1r52ug-0002P0-EB; Mon, 20 Nov 2023 06:58:02 -0500 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=6900L/EC0WYR2fxKpsSRslpbWXjv+NG1QA2vRabAjn4=; b=jrk0AMoR/04C CqEMV+MQPWjbt2N4IQuug2JOzK/oAwRjceuBW32luhBdVoS/ztXEZ1dnR2J5LFvI8MSjb7qiHBNEO Ukh3PXxfGSSVwnWrE7tl8VGd2PoPe+AKTGurbVLacmaHe/o+hLrX4f/ydvduw70HsSYs80fCqtSnw oDWq+CNbPgNbv/FhnvS31UWNbie2+tRGLHmV1g0NSkqBtp9Nzkwo+zB+ynfPkXoO80PjLvw9Gt/Yp uDUcUKkcTh3I3/1n8N9FO1Qs3Bhbt8b7pnoXZCn3jq+FR20RTsBmzAVtgtauv7ejy2MDERhZ2/QiH AbBkuSUoJbLmi5cBbqFXig==; Date: Mon, 20 Nov 2023 13:57:47 +0200 Message-Id: <837cmck56s.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <7d493257-04ab-8325-03af-d9c65236da7a@gutov.dev> (message from Dmitry Gutov on Mon, 20 Nov 2023 04:05:58 +0200) References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> <4b4a190a-ec88-6f50-1f94-900b3afdfc41@gutov.dev> <87sf53m59w.fsf@catern.com> <83a5rbm3j9.fsf@gnu.org> <3bad2052-286b-8532-b9ae-72e8278d5ff3@gutov.dev> <83jzqdkbrp.fsf@gnu.org> <7d493257-04ab-8325-03af-d9c65236da7a@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: Mon, 20 Nov 2023 04:05:58 +0200 > Cc: sbaugh@catern.com, sbaugh@janestreet.com, 66993@debbugs.gnu.org > From: Dmitry Gutov > > So I don't know if project--list is a "minibuffer history", but > depending on the POV one might decide it's close enough. I still think they are different enough for project--list to be out of scope of savehist. But that's me.