bug#11795: 24.1.50; wdired: C-c C-c loses marks and positions of renamed files

[Juri Linkov]

> So, introducing an new option `wdired-keep-marker-rename' would IMHO make
> sense.  The default value could be t, at least that's what I think would
> be most intuitive.

I fixed this regression by adding `wdired-keep-marker-rename'.
Thanks for the suggestion.

When testing it, I noticed a random behavior of `wdired-do-renames' when
the marker is customized to a character.  The decision what character to put
depends on the position of point.  When point is at the top of the Dired
buffer, it uses a customized marker character.  When point is at the bottom,
it restores an old marker character.

The problem is that `dired-remove-file' doesn't remove file entries
(and neither `dired-rename-file') because files already have new renamed names
in the Dired buffer.  Whereas `dired-add-entry' adds duplicated file entries.

Fortunately, `revert-buffer' (called at the end of `wdired-finish-edit')
sorts out this mess caused by `dired-add-entry'.  But in `dired-revert'
it uses `dired-remember-marks' and `dired-restore-positions' to restore
markers.  So when duplicated file entries were added by `dired-add-entry'
at the top of the Dired buffer (in front of file entries edited by WDired),
it uses a customized marker character.  When duplicated file entries
were added at the bottom, it restores an old marker character because
`dired-restore-positions' in `dired-revert' gets markers from the
first duplicated file entry.

Do you have an idea how to fix this problem?  One way would be
instead of using `dired-add-file' to change markers in the remembered
variable `wdired-old-marks' and just call `dired-mark-remembered'
(before `revert-buffer' in `wdired-finish-edit') with the modified
list of markers for renamed files.