From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#63676: cancelling editable dired causes UI problems with dired Date: Sat, 27 May 2023 09:24:26 +0300 Message-ID: <83edn2jnqd.fsf@gnu.org> References: <83ilcing54.fsf@gnu.org> <87jzwupp7n.fsf@web.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35671"; mail-complaints-to="usenet@ciao.gmane.io" Cc: peter.mao@gmail.com, 63676@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 27 08:25:29 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q2nMn-00094C-ND for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 May 2023 08:25:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q2nMQ-0007HY-1e; Sat, 27 May 2023 02:25:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q2nMN-0007Gi-L7 for bug-gnu-emacs@gnu.org; Sat, 27 May 2023 02:25:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q2nMM-0006dN-Dv for bug-gnu-emacs@gnu.org; Sat, 27 May 2023 02:25:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q2nMM-00067R-9T for bug-gnu-emacs@gnu.org; Sat, 27 May 2023 02:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 May 2023 06:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63676 X-GNU-PR-Package: emacs Original-Received: via spool by 63676-submit@debbugs.gnu.org id=B63676.168516864223410 (code B ref 63676); Sat, 27 May 2023 06:25:02 +0000 Original-Received: (at 63676) by debbugs.gnu.org; 27 May 2023 06:24:02 +0000 Original-Received: from localhost ([127.0.0.1]:51269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q2nLN-00065P-Ev for submit@debbugs.gnu.org; Sat, 27 May 2023 02:24:01 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q2nLL-000658-3B for 63676@debbugs.gnu.org; Sat, 27 May 2023 02:24:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q2nLF-0006Sj-Ng; Sat, 27 May 2023 02:23:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3JpkNmoOe51sp3EpsX9jNLObMJUKbf98K5860kVh07A=; b=H9CtX6BEtjIA 6HysLkiiIs74ZZm7bzxIfj+C5rugu/WDafexzA6vHKYkxhQ7hz5CctartVr3lPiA3Wa4sTn/EEGk5 zknWNRl6ys/r3evzf49o9tR8Jj/KsOWtI5fcHPTSpdHPdly+FqfswZqC9+ywoqdNsR3kN30PvB8CN YjNE7VSsQoclMweewu1O7kjHvV4edpqnqWxjdCnFXery+6/mJuxjqOOsa4c+C/yvMYepvwZhoownq cE3MI457HdXzRh0J6vVMymvtWRwchjtTVJAwrBNO4aK4eo0LqiAuGjFsRl272rOBy37nQ7OYJIDMD reLL8sRlx9P90te6JfjZXA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q2nLF-0007L1-5x; Sat, 27 May 2023 02:23:53 -0400 In-Reply-To: <87jzwupp7n.fsf@web.de> (message from Michael Heerdegen on Sat, 27 May 2023 02:55:56 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:262462 Archived-At: > From: Michael Heerdegen > Cc: Peter Mao , 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).