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 14:07:17 -0800 (PST) Message-ID: <39bc6adb-bad1-4e37-a4b6-ef5889348e1d@default> References: <20201229200229.2qdkhuhuir573whz@E15-2016.optimum.net> <310ee0da-94c8-49b3-afd4-4418735aa02e@default> <20201229211819.f6xohj66hpb5dqeg@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="15175"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 23276@debbugs.gnu.org To: Boruch Baum Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 29 23:08: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 1kuNA3-0003qB-6G for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Dec 2020 23:08:11 +0100 Original-Received: from localhost ([::1]:58162 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kuNA2-00005J-7u for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Dec 2020 17:08:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44080) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kuN9v-000059-SN for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 17:08:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57108) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kuN9u-0002kI-Cr for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 17:08:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kuN9u-0006W8-7o for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 17:08:02 -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 22:08:02 +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.160927965425012 (code B ref 23276); Tue, 29 Dec 2020 22:08:02 +0000 Original-Received: (at 23276) by debbugs.gnu.org; 29 Dec 2020 22:07:34 +0000 Original-Received: from localhost ([127.0.0.1]:40421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kuN9R-0006VM-R2 for submit@debbugs.gnu.org; Tue, 29 Dec 2020 17:07:34 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:60504) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kuN9O-0006V8-Ut for 23276@debbugs.gnu.org; Tue, 29 Dec 2020 17:07:32 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BTM5TmD081818; Tue, 29 Dec 2020 22:07:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=v8YE4qCLWsL3bgj3/+K3xXaTGQoFacccHtX8ReVdcjc=; b=jJ7MgRgkjYx7QAuJg76izxiJeDHnhBiyAYN3vPnlUBWGvRFfwGy5BhrYpRVaOebJzBUV strWRnIfulRcXEqcp1p2no34RElkMkzMy1WVvL2Ghqfv4yvJDJ1bs61VUnQnFeXZcEOx 5LnwQVzp6HDCcG8I9oRRpfGgJW86h7LK1tKaxBZENYeAiJG+G/74Qx06AlAr3bSD2buh OLF54XlS+nnTe0JB9026m8ZtaJbN38B91HMnJSAXQVYcBhaqPSFuatKdlcrsi1KTdPHZ XzKlR2we1PC/3/BVlQ3g/g0kQ5FBAbMJqjTSdSgoHrobsBhCElceK5j8RKuKoohiG/iy +w== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 35nvkqqcb2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 29 Dec 2020 22:07:24 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BTLxwOQ100360; Tue, 29 Dec 2020 22:07:24 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 35pexs25w8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Dec 2020 22:07:24 +0000 Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 0BTM7HJV005898; Tue, 29 Dec 2020 22:07:22 GMT In-Reply-To: <20201229211819.f6xohj66hpb5dqeg@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 suspectscore=0 adultscore=0 spamscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012290134 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9849 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 bulkscore=0 adultscore=0 priorityscore=1501 malwarescore=0 impostorscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012290134 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:196982 Archived-At: > > When you use `C-x C-q' to go back to Dired mode from WDired, you are > > in effect saving your changes. >=20 > I was familiar with the "C-c C-c" keybinding, but I tried your > keybinding just now for a simple edit and it work! I don't see it > documented like "C-c C-c" but both *are* bound to the same function. And I in turn forgot about `C-c C-c' here. Actually, `C-c C-c' is a bit better here mentally, in terms of keeping to its typical behavior of "finishing" some editing operation and "sending" the finished result somewhere. > > 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. >=20 > It would also create expectation-conflicts between inside-emacs > expectations and outside-emacs expectations. For example, if outside > emacs I perform a 'shred' operation on a dirtree, I wouldn't want that > operation undone by emacs. I would have a likewise expectation for a > simple delete in an environment that doesn't implement some form of > 'trash-can'. At worst case, I'm imagining emacs performing file-locks on > all elements of huge dirtree in a multi-user environment, all for a > single file rename... First, I don't expect what I'd prefer here to ever be implemented. Second, I don't see how the directory and its contents case is essentially different from the file and its contents case. Of course they're different - a dir is more than just a file. But in the terms considered here, the interactions with a user, and user expectations, seem parallel, to me. You can edit a file in Emacs, and something outside Emacs can delete it from disk while you're editing its buffer. You _can_ (and thank goodness) still save your edits to disk - the file is re-created. OK, it's in fact a new file that's (typically) created, with the same name. And the same would presumably happen for a directory. But nothing prevents an environment from using, say, the trash or some cache to restore either file or dir, and applying the edits implied by implicit diffs. I'm really just saying that there would be some (user) value in having the same or a similar UI to how Emacs deals with file edits. But for some reason, when it comes to WDired, everyone seems to suggest preliminary warnings, confirmation demands or some such, to deal with what is pretty much the same thing: editing and saving edits.