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

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 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).

Something like that indeed. I haven't done measurements. Not that I
practice to have thousands of files in every directory, but those small
delays are still noticable and slightly annoying.

> But yes, it's a problem.

Even if there is just like few tens of files, it saves battery on
laptop if unnecessary processing is ommited :).

>> 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.

Probably; file names are most of a dired buffer; usually there are not
so many symlinks, and permissions are not so much of text.

>> 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`?

Never used 'before-change-function, so I didn't think about it :).

Sure, as a strategy it sounds good indeed, but I am not sure I
understand how to apply that hook in this case. Docs says it is called
before any buffer mdification, but I am not sure what it means: before
every key-press in this case or what is ment with buffer modification here?

> 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.

I agree it shouldn't be noticable; it is how the implementation I
attached works; it is just that I do it explicitly with a "manual"
call to function that change properties just for the line at the point.

Thanks for looking at it.