From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#66993: [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="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14891"; mail-complaints-to="usenet@ciao.gmane.io" To: 66993@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 07 22:28:48 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r0Tcu-0003db-7I for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Nov 2023 22:28:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0TcZ-0004bY-6X; Tue, 07 Nov 2023 16:28:27 -0500 Original-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 1r0TcW-0004bJ-DW for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 16:28:24 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r0TcW-0005CI-5g for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 16:28:24 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r0Td8-0008TG-8P for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 16:29:02 -0500 X-Loop: help-debbugs@gnu.org 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 X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.169939253632547 (code B ref -1); Tue, 07 Nov 2023 21:29:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 7 Nov 2023 21:28:56 +0000 Original-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 Original-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 Original-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 Original-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 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273950 Archived-At: --=-=-= 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 --=-=-=--