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: Fri, 19 Feb 2021 11:10:45 -0800 Message-ID: References: <87h7mllgin.fsf@nexoid.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23997"; 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 Fri Feb 19 20:11:11 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 1lDBBG-00068q-VK for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Feb 2021 20:11:10 +0100 Original-Received: from localhost ([::1]:60740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDBBF-0000np-Jt for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Feb 2021 14:11:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40328) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDBB8-0000nT-OA for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2021 14:11:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38847) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lDBB8-0006NT-GZ for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2021 14:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lDBB8-0003k9-BM for bug-gnu-emacs@gnu.org; Fri, 19 Feb 2021 14:11: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: Fri, 19 Feb 2021 19:11: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.161376186114380 (code B ref 46397); Fri, 19 Feb 2021 19:11:02 +0000 Original-Received: (at 46397) by debbugs.gnu.org; 19 Feb 2021 19:11:01 +0000 Original-Received: from localhost ([127.0.0.1]:50393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDBB6-0003jr-P1 for submit@debbugs.gnu.org; Fri, 19 Feb 2021 14:11:01 -0500 Original-Received: from relay2-d.mail.gandi.net ([217.70.183.194]:52979) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDBB4-0003je-JK for 46397@debbugs.gnu.org; Fri, 19 Feb 2021 14:10:59 -0500 X-Originating-IP: 24.113.169.116 Original-Received: from matts-mbp-2016.lan (24-113-169-116.wavecable.com [24.113.169.116]) (Authenticated sender: matt@rfc20.org) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 8DBFF40002; Fri, 19 Feb 2021 19:10:50 +0000 (UTC) In-Reply-To: <83wnv99xkz.fsf@gnu.org> 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:200376 Archived-At: Eli Zaretskii writes: >> From: Matt Armstrong >> Cc: 46397@debbugs.gnu.org, eggert@cs.ucla.edu, craven@gmx.net >> Date: Sun, 14 Feb 2021 14:16:12 -0800 >> >> When releasing the lock, I have a less clear opinion but I'm thinking >> that warnings are better. A warning is still quite intrusive and >> obvious. Maybe we don't need to decide this part now. > > The problem with warnings is that they can go unnoticed, unless > followed by sit-for. Hello again Eli, Paul, I've got a more concrete plan and would like some feedback on it. While waiting for my signed FSF papers to be acknowledged I have been investigating how to achieve a prompt in some depth. I'm coming to the opinion that issuing a prompt from `unlock-buffer' itself is a bad idea, but I think prompting from `kill-buffer' is okay. I could write a whole essay about why, but instead I'll just propose the following and ask for your thoughts: (a) Modify `kill-buffer' to call `unlock-buffer' sooner, closer to the point where it is already running hooks prompting the user. Handle unlock errors there by prompting. This function already prompts the user for the "buffer modified, save anyway" case so a new prompt there feels fine. (b) Modify Emacs shutdown to handle `unlock-buffer` errors differently as well (with `message' or `display-warning'). (c) Modify `unlock-buffer' to include the buffer name in the errors it signals. It currently only includes the buffer's `buffer-true-filename'. With this the user can more easily find and kill the offending buffer. This approach solves the concrete problems we know about, but doesn't dramatically change Emacs behavior in other ways. In other words, Emacs typically signals errors for file system errors and that stays the same.