bug#23276: autorevert for a deleted dired directory (ref: 23276)

[Drew Adams <drew.adams@oracle.com>]

> > When you use `C-x C-q' to go back to Dired mode from WDired, you are
> > in effect saving your changes.
> 
> 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.
> 
> 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.