From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Date: Thu, 09 Nov 2023 08:32:58 +0200 Message-ID: <835y2b1lnp.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38903"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, 66993@debbugs.gnu.org To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 09 07:33: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 1r0ybr-0009u5-OX for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 Nov 2023 07:33:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0ybV-0000xD-RL; Thu, 09 Nov 2023 01:33:25 -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 1r0ybU-0000wh-0R for bug-gnu-emacs@gnu.org; Thu, 09 Nov 2023 01:33: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 1r0ybT-0004Ej-OF for bug-gnu-emacs@gnu.org; Thu, 09 Nov 2023 01:33:23 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r0yc6-0003J8-B4 for bug-gnu-emacs@gnu.org; Thu, 09 Nov 2023 01:34:02 -0500 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.169951163712701 (code B ref 66993); Thu, 09 Nov 2023 06:34:02 +0000 Original-Received: (at 66993) by debbugs.gnu.org; 9 Nov 2023 06:33:57 +0000 Original-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 Original-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 Original-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==; In-Reply-To: (message from Spencer Baugh on Wed, 08 Nov 2023 15:43:53 -0500) 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:274029 Archived-At: > 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!"