From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#23276: autorevert for a deleted dired directory (ref: 23276) Date: Tue, 29 Dec 2020 12:24:19 -0800 (PST) Message-ID: <310ee0da-94c8-49b3-afd4-4418735aa02e@default> References: <20201229200229.2qdkhuhuir573whz@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9237"; mail-complaints-to="usenet@ciao.gmane.io" To: Boruch Baum , 23276@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 29 21:27:11 2020 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 1kuLaI-0002FT-Bk for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Dec 2020 21:27:10 +0100 Original-Received: from localhost ([::1]:59158 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kuLaG-0006Nc-Oq for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Dec 2020 15:27:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55832) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kuLaA-0006NQ-4a for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 15:27:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56978) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kuLa9-0002j1-Ru for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 15:27:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kuLa9-0003mG-LB for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 15:27:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Dec 2020 20:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23276 X-GNU-PR-Package: emacs Original-Received: via spool by 23276-submit@debbugs.gnu.org id=B23276.160927359114482 (code B ref 23276); Tue, 29 Dec 2020 20:27:01 +0000 Original-Received: (at 23276) by debbugs.gnu.org; 29 Dec 2020 20:26:31 +0000 Original-Received: from localhost ([127.0.0.1]:40291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kuLZf-0003lV-4b for submit@debbugs.gnu.org; Tue, 29 Dec 2020 15:26:31 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:33730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kuLZd-0003lH-6U for 23276@debbugs.gnu.org; Tue, 29 Dec 2020 15:26:29 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BTKOeKD159671; Tue, 29 Dec 2020 20:26:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=9U5kaBZotbfR3PqoplxTybjs1RKkWogIANsg9eBoSCE=; b=veIpTXm2+hcGN6y9o3bujPw6hx1vymiN3WfqRNGfFVRD2kcO3/+vNEP9AXwfZeosrIzF 6zgc+lVlMsc9JmEbAWdX6mS13bg7HiJhxir2mAv9wurL09XZHWSe+DNRpIhUFQVNoCRa 2Hj6dpDfg38L1Bj0N4230kOqI6HAeo9fhE1UoYMIrgj9ZYZj0bX4NRkV8mYQ7MCZtEXP MrQuvMjZVSmAq8ru+S+G46CnpAExhp66D+AGPvlpQN+5nzFoVBllzINh2QphvQF7yUgw 5gzWOr4hTAFZ0mXVb85AUk7JFhYEnSs6sXzMtgxLvcA6Vmp4Ys91GyOTok7L1Z+mceps xg== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 35phm1e4qr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 29 Dec 2020 20:26:23 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BTKKwi4179123; Tue, 29 Dec 2020 20:24:22 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 35pf3x2db5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Dec 2020 20:24:22 +0000 Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0BTKOKXY024630; Tue, 29 Dec 2020 20:24:21 GMT In-Reply-To: <20201229200229.2qdkhuhuir573whz@E15-2016.optimum.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5095.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9849 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 suspectscore=0 spamscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012290124 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9849 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=999 adultscore=0 bulkscore=0 malwarescore=0 spamscore=0 impostorscore=0 phishscore=0 clxscore=1011 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012290125 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:196973 Archived-At: > I don't see in that long discussion treatment of the case of a dired > buffer when the directory it describes is deleted. In such a case, there > isn't any meaningful recovery operation that I can think of, and any > attempted operation on the buffer would only be a waste of time and > throw errors. >=20 > The biggest waste-of-time case that I can think of would be entering > wdired-mode on the buffer. I've tried it and it only throws an error on > exit, so a user could spend significant time editing the buffer for > naught. Of course, a solution for that specific case could be coded > outside of autorevert, to have wdired-mode itself refuse to operate on a > non-existent dired directory >=20 > (unless (file-directory-p dired-directory) > ... >=20 > which might be a good idea anyway, but it doesn't address all the other > less potentially time-consuming dired operations. >=20 > Personally, I wouldn't want to see the buffer deleted, because that > would mess up package diredc (shameless promo interruption: now on > MELPA!), but the buffer could be somehow prominently labeled as > describing a now-deleted directory, maybe in bold the top visible line. > That way a user would have a record of what was deleted, and would know > that the contents are only documentary and not operational. I've coded > handling in diredc for its history and navigation functions, but there > are also all the 'normal' dired operations to take into account by all > the normal dired users. My own take is different. I think the behavior should be similar to what we do for a file. The only difference I can think of (so far) is that the notion of "saving" the changes is combined with the notion of turning off read-only. For a file those are two different things: `C-x C-q' doesn't save editing changes to disk. When you use `C-x C-q' to go back to Dired mode from WDired, you are in effect saving your changes. If you're in WDired making changes, and something - ANYTHING, inside or outside Emacs - deletes the directory, then what should happen is that when you try `C-x C-q' to save your changes, the directory and its files and subdirs are created, so that the Dired buffer is made to correspond to the changes you made. That may not be easy to implement. But ideally that's the behavior I'd like: just like saving changes to a file buffer, if something - ANYTHING - deletes the file while you're editing its buffer.