Re: 23.0.50; Deleting files in wdired does not work

[martin rudalics <rudalics@gmx.at>]

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?