From: Drew Adams <drew.adams@oracle.com>
To: Boruch Baum <boruch_baum@gmx.com>, 23276@debbugs.gnu.org
Subject: bug#23276: autorevert for a deleted dired directory (ref: 23276)
Date: Tue, 29 Dec 2020 12:24:19 -0800 (PST) [thread overview]
Message-ID: <310ee0da-94c8-49b3-afd4-4418735aa02e@default> (raw)
In-Reply-To: <20201229200229.2qdkhuhuir573whz@E15-2016.optimum.net>
> 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.
next prev parent reply other threads:[~2020-12-29 20:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 11:07 bug#23276: 25.0.92; Crash in auto-revert when file no longer present Anders Lindgren
2016-04-12 15:16 ` Eli Zaretskii
2016-04-12 16:14 ` Michael Albinus
2016-04-16 18:44 ` Michael Albinus
2016-04-16 18:55 ` Anders Lindgren
2016-04-16 20:56 ` Michael Albinus
2016-04-16 19:00 ` Eli Zaretskii
2016-04-16 20:35 ` Michael Albinus
2016-04-16 20:56 ` Anders Lindgren
2016-04-16 21:30 ` Michael Albinus
2016-04-17 1:54 ` John Wiegley
2016-04-17 2:39 ` Eli Zaretskii
2016-04-17 2:53 ` John Wiegley
2016-04-17 2:57 ` John Mastro
2016-04-17 8:52 ` Michael Albinus
2016-04-18 8:26 ` Michael Albinus
2016-04-17 13:20 ` Óscar Fuentes
2016-04-17 15:16 ` Eli Zaretskii
2016-04-17 16:01 ` Óscar Fuentes
2016-04-17 16:10 ` Eli Zaretskii
2016-04-18 8:24 ` Michael Albinus
2020-12-29 20:02 ` bug#23276: autorevert for a deleted dired directory (ref: 23276) Boruch Baum
2020-12-29 20:13 ` Eli Zaretskii
2020-12-29 20:45 ` Boruch Baum
2020-12-29 20:24 ` Drew Adams [this message]
2020-12-29 21:18 ` Boruch Baum
2020-12-29 22:07 ` Drew Adams
2022-04-27 14:09 ` bug#23276: 25.0.92; Crash in auto-revert when file no longer present Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=310ee0da-94c8-49b3-afd4-4418735aa02e@default \
--to=drew.adams@oracle.com \
--cc=23276@debbugs.gnu.org \
--cc=boruch_baum@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.