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

[Boruch Baum <boruch_baum@gmx.com>]

First, thanks to everyone/anyone who documented bug 23276 in the body of
file autorevert.el. Because of that in-line documentation, I was able to
easily find and read the relevant historical discussion.

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.

NOTE: Because I'm picking up on this thread from the web interface, I
don't have many of the email addresses that contributed to the thread,
so at this point I'm hoping the server will auto-magically copy anyone
who should be copied.

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