Re: 23.0.50; Deleting files in wdired does not work

[martin rudalics]

Thank you for your report and the patch.  Sorry for the delay in
answering it.

> It looks like wdired-get-filename adds a spurious newline to the result
> whenever the filename has been deleted in wdired.

The 'end-name text property assigned by `wdired-preprocess-files' covers
exactly one character after the filename, usually the newline.  Deleting
the filename and calling `next-single-property-change' from (1+ beg)
will thus return the position after the newline and set `file' to "\n"
in `wdired-get-filename' - as you observed.  For the last filename the
'end-name text-property remains constant till the end of the buffer,

          (setq end (next-single-property-change (1+ beg) 'end-name))

returns nil, and the subsequent

          (setq file (buffer-substring-no-properties (1+ beg) end)))

fails with a "Wrong type argument: integer-or-marker-p, nil", am I
right?  Hence, you indeed detected two different bugs.

> In addition, in
> wdired-finish-edit, to test whether a filename has been deleted, we should 
look
> at (wdired-get-filename t), which returns the basename only, and see whether 
it
> equals "".
>
> I propose the following patch:

Your patch fixes both bugs.  However, I'd prefer if you replaced the
original

          (setq end (next-single-property-change (1+ beg) 'end-name))

by something like the untested

          (if (get-text-property (1+ beg) 'end-name)
              ""
            (setq end (next-single-property-change (1+ beg) 'end-name))
            (setq file (buffer-substring-no-properties (1+ beg) end))))

It would allow this part of wdired to also work in the case where the
filename does not appear at the end of the line in dired listings.  I
don't know how realistic that is - but we shouldn't hardcode anything
into wdired which wasn't there initially.  Could you try to do that?