Re: Keeping replace-buffer-contents runtime in bounds

[Tassilo Horn]

Eli Zaretskii <address@hidden> writes:

>> In the end I settled for a maximum number of seconds one can define
>> by setting a new variable replace-buffer-contents-max-secs, so that
>> you can define what's still acceptable in the respective use-case.
>> (Actually, if you set that to 1.5 or so, it may still run for 2 or
>> more seconds because the EARLY_ABORT expression isn't tested at
>> regular intervals or rather it is, but the intervals don't take
>> equally long.)
>> 
>> If that number of seconds is over, compareseq returns early and
>> replace-buffer-contents falls back to plain delete and insert.
>
> The gotcha about aborting after more than the time-out value should be
> mentioned in the doc string.
>
> Thanks for working on this.  My only other comment is that maybe we
> should allow passing the time-out value via the function's arguments,
> not via a global variable.  It seems to me the time-out will be used
> in more use cases than MAX-COSTS, and in any case treating these two
> differently API-wise sounds strangely inconsistent.

I've done that and landed it in master.

The downside of having the MAX-* arguments instead of global variables
is that now we have a json-pretty-print-max-secs global variable because
somewhere a user has to specify how long he is willing to wait.  But I
guess the JSON scenario is pretty unique in the size and diffs of the
replaced text, so that's allright from my POV.

I also changed the return value of replace-buffer-contents so that now t
means the non-destructive replacement worked as advertised, and nil
means we fell back to delete-region and insert-buffer-substring.  Using
t for success just seemed more natural for me.

Bye,
Tassilo