Re: [RFC]: replace-region-contents

[Tassilo Horn <tsdh@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> I've set too_expensive to 64 because then my benchmark was almost as
>> fast as the original version without `replace-buffer-contents', and I
>> couldn't find any difference in observable behavior in that value anyway
>> except lower values give much better performance but a too low value
>> like 10 will segfault.  My main concern was that point was at the same
>> position before and after pretty-printing my JSON.
>
> I'd prefer to expose this to Lisp, not hardcode the value.  We could
> use the hardcoded value in json.el, but I'd like to leave this to the
> application in the other cases.  I'm not sure such a small value will
> always be the right tradeoff, so I think we shouldn't decide just yet.
>
> If you agree with that, let's expose this via a new optional argument
> to replace-buffer-contents, and let's treat the value of nil as a very
> large integer value, i.e. "no limit".

Done on branch scratch/replace-region-contents.

>> --- a/src/editfns.c
>> +++ b/src/editfns.c
>> @@ -1910,6 +1910,11 @@ determines whether case is significant or ignored.  */)
>> +#define USE_HEURISTIC
>> +
>> +#ifdef USE_HEURISTIC
>> +#define DIFFSEQ_HEURISTIC
>> +#endif
>> @@ -2017,8 +2022,11 @@ differences between the two buffers.  */)
>>      .insertions = SAFE_ALLOCA (ins_bytes),
>>      .fdiag = buffer + size_b + 1,
>>      .bdiag = buffer + diags + size_b + 1,
>> +#ifdef DIFFSEQ_HEURISTIC
>> +    .heuristic = true,
>> +#endif
>
> Why do we need this triple-level conditional?  If we think the
> heuristic is a good idea, let's just enable it unconditionally.  If
> someone wants to modify Emacs on the C level, they can edit the source
> as easily as they can invoke the compiler with a -U switch.

Removed.

Shall I also move replace-region-contents from subr.el to subr-x.el?

> Finally, I think this needs NEWS entries, both regarding the new
> function and the additional argument to replace-buffer-contents.  The
> latter is also documented in the ELisp manual, which will need to be
> updated.

I'll write that when everybody is ok with the code.

> P.S.  I still hope Paul will chime in and comments on the diffseq bits
> we are modifying here.

Oh, yes, please.

Bye,
Tassilo