bug#63676: cancelling editable dired causes UI problems with dired

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Peter Mao <peter.mao@gmail.com>,  63676@debbugs.gnu.org
> Date: Sat, 27 May 2023 02:55:56 +0200
> 
> I think this should be appropriate:

Thanks, but why removal of the comment? is the comment incorrect or
inaccurate?  I think having comments that explain why we do
non-trivial things is an advantage.

> Background: Aborting wdired (`wdired-abort-changes') erases the
> buffer and insert the original buffer contents, then re-enters
> dired-mode.  Positions in `dired-subdir-alist' (that are necessary for
> $) are represented as markers.  These just have to be updated.

Are we sure this is the _only_ thing that needs to be updated?
dired-revert does much more, so we should audit what it does carefully
to determine which parts may need re-doing here.  If you did that,
would you please present the analysis and the conclusions?  In
particular, wdired-abort-changes could be called after more commands
than the original recipe shows, and that could affect other aspects of
the Dired buffer, not just dired-subdir-alist.

> A less invasive way of aborting wdired could just undo any user changes.
> I think this should be doable using change groups.  Then we would not
> loose any kind of marker positions.  `wdired-finish-edit' does not
> suffer from these kind of problems because it only touches buffer parts
> that correspond to changed file lines.  Currently aborting is more
> invasive than actually making changes.

This change was installed in the emacs-29 branch.  Any alternative
change, if we want it in Emacs 29, should be both safe (in the sense
that its code doesn't risk breaking other things) and reliable (in the
sense that it solves the original problem in its entirety).  If we can
come up with such an alternative, fine; otherwise what you propose
might be good for experimenting on the master branch, but not for the
release branch.

And having said all that, I don't really understand why we should
worry so much about the downsides of the solution: is
wdired-abort-changes something that is used a lot?  At least its speed
sounds not important at all, and if the information it loses is indeed
important enough, the way to avoid that is to restore that information
after reverting, perhaps the way wdired-finish-edit does (which, btw,
does call revert).