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

[Stephen Berman]

On Fri, 27 Jul 2018 10:09:25 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: enrico.scholz@ensc.de,  32173@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.
[...]
> Thanks.  I think we should install your original and safer patch on
> the release branch, and this more thorough fix on master.  WDYT?

Sounds reasonable.  Should we give the OP a bit longer to react or
should I just go ahead and commit the fixes (in any case, I may not be
able to until tomorrow or Sunday)?

I also wrote three tests, two for the bug with non-nil
wdired-use-interactive-rename, one where the edit is finished and one
where it's aborted, and one test for unfinished edits (it might be nice
to have a variant of the latter that uses dired-isearch-filenames, but I
don't see any straightforward way to emulate isearch in the test
environment).  The first two tests are suitable for both fixes, but the
third test only succeeds with the fix intended for master, so I use the
:expected-result keyword in the test definition.  But should I install
the test file on each branch as part of the commit with the respective
fix (which won't be merged from release to master), or should I make a
separate commit of the test file just to the release branch and let it
be merged to master?

Steve Berman