I spent some time thinking on how to get this new revert command
integrated with the rest of revert-buffer functions, and I came up with
the attached patch.
Since the difference between revert-buffer and
revert-buffer-with-fine-grain lies at the insert-file-contents level, I
wrote an alternative to
revert-buffer-insert-file-contents--default-function, that uses
replace-buffer-contents, as Eli suggested. I named it
revert-buffer-insert-file-contents-delicately.
Then, revert-buffer-with-fine-grain only needs to bind
revert-buffer-insert-file-contents-function to
revert-buffer-insert-file-contents-delicately to get the job done.
There are some more things that revert-buffer-with-fine-grain needs to
do:
1) Manipulate the current-prefix-arg, just like revert-buffer does.
2) Since replace-buffer-contents can fail to replace conservatively,
return that information could be useful. But revert-buffer--default
always returns t after reverting, so I used a closure that then gets
called by revert-buffer-with-fine-grain.
To control how much time replace-buffer-contents spends trying to be
non-destructive, I introduced a new variable to pass as the MAX-SECS
argument. 2.0 secs looks like a good value, according to the previous
benchmark I posted, and the new one I post here. I think it should be
an acceptable delay.
As I said above, I timed the command, and to compare I timed
revert-buffer too. IMO, the results look good. Some files fail and
take a lot of time, yes, but I think it's unlikely that a user will revert
so many changes. And for those, at least the variable
revert-buffer-with-fine-grain-max-seconds helps to terminate the
execution earlier.
I also went ahead and wrote a test for revert-buffer-with-fine-grain,
because I figure it would be required, as well as the benchmarking.
As I was there, I wrote a similar test for revert-buffer.
Corrections and comments are welcome. Better names too.
Best regards,
Mauro.
bug18-benchmark.txt