GNU bug report logs - #32173
26.1; wdired: broken 'wdired-use-interactive-rename'

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 32173 <at> debbugs.gnu.org, enrico.scholz <at> ensc.de
Subject: bug#32173: 26.1; wdired: broken 'wdired-use-interactive-rename'
Date: Fri, 27 Jul 2018 10:09:25 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: enrico.scholz <at> ensc.de,  32173 <at> debbugs.gnu.org
> Date: Sun, 22 Jul 2018 01:38:44 +0200
> 
> > Btw, what happens in the non-interactive rename case, wrt the
> > dired-filename property?  If the renamed file is left with part of it
> > covered by that property, we may have a broader problem in wdired.el.
> 
> That's a good question (which didn't occur to me).  With
> wdired-use-interactive-rename nil (the default), a partially edited
> filename is indeed only partly covered by the dired-filename property,
> but as soon as you type C-c C-c or C-x C-s the change is saved and the
> buffer returns to dired-mode, which makes the whole file name
> propertized again.  So that's no problem.  However, there could be a
> problem before saving the change if some function looks for the
> dired-filename property -- and in fact, there is such a function:
> dired-isearch-filenames in dired-aux.el.  And indeed, you can use this
> in wdired-mode after editing file names but before saving the changes,
> and then the search will fail if the search string includes characters
> now lacking the dired-filename property.
> 
> The only way I could think of to avoid this is to restore the text
> property via after-change-functions, as in the patch below.  I'm not so
> confident that this is the best approach, but it seems to work, in that
> AFAICT it fixes the bug with non-nil wdired-use-interactive-rename and
> also handles the non-interactive case, allowing dired-isearch-filenames
> to function as expected.  Maybe there's a less heavy-handed way to get
> this, but none has occurred to me.
> 
> It was also necessary to move the invocation of
> wdired-change-to-dired-mode in wdired-finish-edit to after the
> invocation of wdired-do-renames, since calling it before meant the
> buffer was in dired-mode, which doesn't use the after change function,
> so typing C-g on being prompted to accept the change would have left a
> partially unpropertized file name.  (The invocation of
> wdired-change-to-dired-mode also has to be before the invocation of
> revert-buffer in wdired-finish-edit to avoid using wdired-revert, which
> changes to dired-mode and then back to wdired-mode.)
> 
> Finally, a consequence of moving wdired-change-to-dired-mode is that
> with typing C-g with non-nil wdired-use-interactive-rename leaves the
> buffer in wdired-mode, instead of returning to dired-mode as it
> currently does.  To keep the current behavior I wrapped an extra call to
> wdired-change-to-dired-mode in unwind-protect in
> wdired-search-and-rename.

Thanks.  I think we should install your original and safer patch on
the release branch, and this more thorough fix on master.  WDYT?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.