From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.bugs Subject: bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file Date: Wed, 24 Feb 2021 09:37:49 -0800 Message-ID: References: <83sg5r276b.fsf@gnu.org> <838s7j14xc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30348"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46397@debbugs.gnu.org, eggert@cs.ucla.edu, craven@gmx.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 24 18:39:29 2021 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 1lEy8G-0007lf-Qm for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Feb 2021 18:39:28 +0100 Original-Received: from localhost ([::1]:44424 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lEy8F-0003z5-TW for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Feb 2021 12:39:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54428) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lEy7s-0003y7-4l for bug-gnu-emacs@gnu.org; Wed, 24 Feb 2021 12:39:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52529) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lEy7q-0003bv-4F for bug-gnu-emacs@gnu.org; Wed, 24 Feb 2021 12:39:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lEy7q-00007S-2F for bug-gnu-emacs@gnu.org; Wed, 24 Feb 2021 12:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Matt Armstrong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Feb 2021 17:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46397 X-GNU-PR-Package: emacs Original-Received: via spool by 46397-submit@debbugs.gnu.org id=B46397.1614188283383 (code B ref 46397); Wed, 24 Feb 2021 17:39:02 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 24 Feb 2021 17:38:03 +0000 Original-Received: from localhost ([127.0.0.1]:35842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEy6s-000066-Mv for submit@debbugs.gnu.org; Wed, 24 Feb 2021 12:38:02 -0500 Original-Received: from relay11.mail.gandi.net ([217.70.178.231]:48233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEy6q-00005b-R0 for 46397@debbugs.gnu.org; Wed, 24 Feb 2021 12:38:01 -0500 Original-Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay11.mail.gandi.net (Postfix) with ESMTPSA id DAACB100008; Wed, 24 Feb 2021 17:37:52 +0000 (UTC) In-Reply-To: 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" Xref: news.gmane.io gmane.emacs.bugs:200745 Archived-At: Matt Armstrong writes: > Eli Zaretskii writes: [...] >> I think we should audit all the callers of unlock_buffer and >> unlock_file, and see if signaling an error there is really the best >> alternative. [...] Eli, no rush but I wanted to be clear that I have paused work on this bug until I get more feedback from you. At this point I don't have any more avenues that I feel I can explore, and I am unsure what more you'd like to see before we move forward with a decision here. I'm willing to work toward any of the options I outline below, or something new that I have not considered. I still like my original idea of calling display-warning for all unlock errors, essentially turning "unlock" into a best effort function at the API level. I think display-warning is intrusive enough that users are unlikely to simply not notice the problem, and there are worse things than leaving lock files around. I could see prompting for all errors from unlock-buffer itself, but I have concerns about it. As my analysis showed, the unlock operation happens in potentially thousands of call sites in Emacs core alone. This not counting third party elisp code. It escallates an error to a user interaction, which defeats mechanisms like with-demoted-errors and other uses of condition-case. Short of my display-warning idea, I think a reasonable option is to handle unlock errors in targeted places. This isn't a particularly radical idea, I think. The only two we know to be very problematic for users is kill-buffer and kill-emacs. That is my summary of where the discussion is at. Let me know how you'd like to proceed.