Eli Zaretskii <[email protected]> writes:
>> From: Alex Bennée <[email protected]>
>> Cc: Stefan Monnier <[email protected]>, [email protected],
>> [email protected], [email protected], [email protected]
>> Date: Tue, 19 Jul 2016 18:05:37 +0100
>>
>> > Do we care that using save-match-data in every call to replace-match
>> > might mean a performance hit? If it will, then this will again punish
>> > most of the users for the benefit of those few who (1) have
>> > buffer-modification hooks, and (2) those hooks call save-match-data.
>>
>> I care unless there is an easy way to identify which buffer modification
>> hooks are responsible so I can take steps as a user to mitigate the
>> problems.
>
> Any hook in before-change-functions or after-change-functions that
> calls save-match-data.
>
> If we care about the performance hit, we need to come up with a
> different solution for this problem (or measure the performance hit
> and convince ourselves it is not a big deal).
Thanks for the hint. So in my case it was flycheck-handle-change which
was triggering the problem:
(defun flycheck-handle-change (beg end _len)
"Handle a buffer change between BEG and END.
BEG and END mark the beginning and end of the change text. _LEN
is ignored.
Start a syntax check if a new line has been inserted into the
buffer."
;; Save and restore the match data, as recommended in (elisp)Change Hooks
(save-match-data
(when flycheck-mode
;; The buffer was changed, thus clear the idle timer
(flycheck-clear-idle-change-timer)
(if (string-match-p (rx "\n") (buffer-substring beg end))
(flycheck-buffer-automatically 'new-line 'force-deferred)
(setq flycheck-idle-change-timer
(run-at-time flycheck-idle-change-delay nil
#'flycheck-handle-idle-change))))))
However it doesn't look as though it tweaks the buffer until idle timer
has run. Weird....
--
Alex Bennée
