Re: Partial wdired (edit just filename at the point)

[Stefan Monnier]

> Wdired is really nice for batch renaming files, but I have noticed that
> in case there are lots of files, starting wdired mode and finalizing
> changes can take a while. Sometimes I switch to wdired mode just to rename
> a single file. On my machine, a directory with ~700 - 800 files causes
> a noticable delay. I haven't measured but it is in range of 2-3
> seconds I would guess. I had one directory with almost 2000 files and
> when tested it took quite a bit of time.

It seems to scale linearly, so it will indeed get slower with very large
directories, tho it should stay manageable (i.e. if it took 2-3s for
700 files, it should still take less than 6-9s for 2000 files).

But yes, it's a problem.

> I traced it down to how dired/wdired use text properties to controll if
> text is writable or not. When switching to, wdired goes three times
> through entire buffer (filenames, perms and symlinks) and changes text
> properties to writable text.

The profiler suggests that most of the time is spent in
`wdired-preprocess-files` which does one of those traversals.

> I have rewritten those few functions to drop to wdired mode to only work
> on a line under the point; it is just quick copy/paste hack.  It
> works fine for my needs and wdired starts without noticable delay, but
> there is one cosmetic detail: despite me changing properties only for
> current line, wdired still let me edit other text in dired buffer
> itself.

I'd rather try and speed up the general code.  How 'bout making
`wdired-preprocess-files` work one line at a time and do it lazily,
using a `before-change-function`?

This way entering `wdired` should be instantaneous but you can still
edit any line you like.  The actual edits would be slightly slowed down,
but that shouldn't be nearly as problematic.


        Stefan