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

[Boruch Baum]

On 2020-12-29 12:24, Drew Adams wrote:
> 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.

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.

>
> 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...

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0