[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Keeping replace-buffer-contents runtime in bounds
From: |
Tassilo Horn |
Subject: |
Re: Keeping replace-buffer-contents runtime in bounds |
Date: |
Sun, 24 Feb 2019 11:11:51 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
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
- Keeping replace-buffer-contents runtime in bounds, Tassilo Horn, 2019/02/16
- Re: Keeping replace-buffer-contents runtime in bounds, Eli Zaretskii, 2019/02/17
- Re: Keeping replace-buffer-contents runtime in bounds, Tassilo Horn, 2019/02/17
- Re: Keeping replace-buffer-contents runtime in bounds,
Tassilo Horn <=
- Re: Keeping replace-buffer-contents runtime in bounds, Eli Zaretskii, 2019/02/24
- Re: Keeping replace-buffer-contents runtime in bounds, Philipp Stephani, 2019/02/24
- Re: Keeping replace-buffer-contents runtime in bounds, Tassilo Horn, 2019/02/25
- Re: Keeping replace-buffer-contents runtime in bounds, Tassilo Horn, 2019/02/25
- Re: Keeping replace-buffer-contents runtime in bounds, Stefan Monnier, 2019/02/25
- Re: Keeping replace-buffer-contents runtime in bounds, Tassilo Horn, 2019/02/26