unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Heerdegen <michael_heerdegen@web.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: peter.mao@gmail.com, 63676@debbugs.gnu.org
Subject: bug#63676: cancelling editable dired causes UI problems with dired
Date: Sun, 28 May 2023 05:39:34 +0200	[thread overview]
Message-ID: <87r0r15dl5.fsf@web.de> (raw)
In-Reply-To: <83edn2jnqd.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 27 May 2023 09:24:26 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

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

Ok, I now had another look.  The only thing that aborting does not
100%-cleanly revert is: if option `wdired-search-replace-filenames' is
non-nil, wdired does some setup for isearch to enable the user to
query-replace only in filenames (and ignore other buffer parts).  If the
user disables that option after entering wdired, but before aborting,
the current code doesn't revert those modifications to isearch
functions.  [ Note that calling dired-revert does not help here because
it doesn't touch buffer local variables ].  I think that needs fixing,
although it is unlikely that somebody does that.

The other modifications to the dired buffer are all restored carefully.

What's left are effects that could be caused by restoring the buffer
contents with the old contents when reverting (like this issue here).

`dired-build-subdir-alist' is the only thing in dired that uses markers
not only temporarily.  All other markers are used to ease operations and
are thrown away after the operation is finished.  Overlays are not used
at all.

Text properties and file marks (those like "*") are part of the saved
buffer contents and are restored along with the contents.

Things like re-registering the dired buffer are done (`dired-advertize')
accordingly.

Some things also have already been fixed AFAIR (like the cooperation of
dired-hide-details-mode and wdired).  People have been using and testing
aborting for a long time.  I think nearly everything would have been
uncovered until now: recent related bug reports mostly discovered
problems related to recent changes to dired that not yet had been
handled by the wdired code.

It's a complex matter but I don't have more useful ideas what else could
go wrong that a `dired-revert' would fix (or not; in general).  From my
perspective my suggested change and the quality of dired and wdired wrt
this change is quite safe.


Michael.





  parent reply	other threads:[~2023-05-28  3:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-24  4:51 bug#63676: cancelling editable dired causes UI problems with dired Peter Mao
2023-05-24 11:05 ` Eli Zaretskii
2023-05-24 12:09   ` Stephen Berman
2023-05-25  1:14   ` Peter Mao
2023-05-26  9:25     ` Eli Zaretskii
2023-05-26 23:51   ` Michael Heerdegen
2023-05-27  0:55   ` Michael Heerdegen
2023-05-27  2:39     ` Michael Heerdegen
2023-05-27  6:26       ` Eli Zaretskii
2023-05-27  6:24     ` Eli Zaretskii
2023-05-28  1:36       ` Michael Heerdegen
2023-05-28  4:09         ` Thierry Volpiatto
2023-05-28  5:01           ` Michael Heerdegen
2023-05-28  5:08             ` Thierry Volpiatto
2023-05-28 16:04             ` Drew Adams
2023-05-28 16:21               ` Thierry Volpiatto
2023-05-28 19:17                 ` Drew Adams
2023-05-29  3:43                   ` Thierry Volpiatto
2023-05-29  5:16                     ` Drew Adams
2023-05-29  9:43                       ` Thierry Volpiatto
2023-05-29 17:11                         ` Drew Adams
2023-05-28 16:05           ` Drew Adams
2023-05-28  3:39       ` Michael Heerdegen [this message]
2023-05-28  6:43         ` Eli Zaretskii
2023-05-29  1:35           ` Michael Heerdegen

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r0r15dl5.fsf@web.de \
    --to=michael_heerdegen@web.de \
    --cc=63676@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=peter.mao@gmail.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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).