Re: [PATCH] Lazy wdired preprocessing

[Arthur Miller]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Haven't got any repsonses, but for me it seems to work fine. Maybe I
>> haven't tested some use-case though.
>
> I have understood what you want to achieve.  Could you please say one or
> two sentences about what the purpose of the changes in wdired.el is -
> are they necessary to make lazy-wdired.el work, or are there user
> visible changes (improvements) already for wdired.el alone?

Lazy-wdired.el was just my working file, I sent it for the convenience:
if anyone wishes to easily test without need to apply patch to
wdired.el, but patch is what it is about; i.e. you can throw away
lazy-wdired.el :). 

This was re-implementation of parts of wdired to make it more efficient
and faster to enter the wdired mode.

This patch makes wdired process only those lines in a region where
changes are requested, in interactive cases usually just one line at a
time. That makes it always same cost to enter wdired and possibly also
saves some battery life when user does not mean to edit all file names.
Price is somewhat slower editing per line, but I can't notice any
slowdowns or delays on my computer.

If you check original code, it will pre-process entire dired buffer to
make some part of dired non-editable. On directories with large number
of files (~500+) that results in a noticable delay when entering wdired
mode.

There are no user-visible changes, other then a refusing to enter wdired
when there are no files in a directory. I could remove that error, but I
don't think there is purpose to enter writable dired for empty
directory. I hope it is correct assumption.

So it is just a little optimization.