GNU bug report logs - #23276
25.0.92; Crash in auto-revert when file no longer present

Previous Next

Full log

Message #82 received at 23276 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Boruch Baum <boruch_baum <at> gmx.com>, 23276 <at> debbugs.gnu.org
Subject: RE: bug#23276: autorevert for a deleted dired directory (ref: 23276)
Date: Tue, 29 Dec 2020 12:24:19 -0800 (PST)

> 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.
> 
> 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
> 
>   (unless (file-directory-p dired-directory)
>     ...
> 
> which might be a good idea anyway, but it doesn't address all the other
> less potentially time-consuming dired operations.
> 
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.