bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents

[Stefan Monnier]

>> Keep track of the first and last char actually modified (or,
>> equivalently, keep track of the number of chars unmodified at the
>> beginning and at the end, as this is often easier).
>
> Is that worth the hassle?  The caller asked to replace the entire
> buffer by something else, why should they expect after-change hooks to
> be run on something other than the entire buffer?

IIUC replace-buffer-contents is meant to be used in cases where there's
a good probability that the old and new contents are almost identical,
save for a few details here and there.

So, it may very well be the case that out of the 1MB that is covered by
BEGV..ZV only 10bytes in the middle were deleted/inserted/modified, in
which case running a-c-f on those 10bytes will likely lead to
a significantly more efficient recomputation for things like font-lock.

This refinement is not indispensable, but we make this effort in pretty
much every other similar circumstance.  It's usually fairly easy/cheap
to provide those tighter bounds.


        Stefan