bug#32673: 27.0.50; wdired: broken 'wdired--restore-dired-filename-prop'

[Juri Linkov <juri@linkov.net>]

> The immediate cause of this is that wdired--restore-dired-filename-prop,
> which is on after-change-functions, calls dired-get-filename without
> making sure that the file name is not the empty string.  But it turns
> out that using dired-get-filename in that function also doesn't work
> with symlinks as I had thought (and tested, but evidently not enough):
> after enabling wdired-mode but before making a change, (file-symlink-p
> (dired-get-filename)) on a symlink returns the name of the target, but
> as soon as a change is made, that sexp returns nil, which causes a
> text-read-only signal.  The patch below replaces this sexp and according
> to my tests avoids the error which breaks delete-selection-mode and also
> most text-read-only signals (one remains: when deleting the whole link
> name; I haven't been able to figure out how to avoid that).  The patch
> should get more testing (in particular, is looking for the `l' flag a
> reliable way to identify a symlink?), and an ERT test would also be
> good, but I probably can't do either for the next few weeks, because
> I'll be travelling.  I can install the patch before I leave, since it
> seems at least better than the status quo, or maybe someone else can
> take a look and either confirm that it is good enough or else come up
> with a better fix.

Thanks, since your patch fixes the reported problem, there is no reason
to postpone installing it.  Regarding improving the handling of symlinks,
maybe you can use some code from dired-move-to-end-of-filename,
especially handling dired-ls-F-marks-symlinks.