Re: Keeping replace-buffer-contents runtime in bounds

[Philipp Stephani]

Am So., 24. Feb. 2019 um 11:12 Uhr schrieb Tassilo Horn <address@hidden>:
>
> 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.


Thanks. However, the variable replace-buffer-contents-max-secs is
still present, did you maybe keep it by mistake?