Eli Zaretskii <e...@gnu.org> writes:

>> From: Alex Bennée <alex.ben...@linaro.org>
>> Cc: Stefan Monnier <monn...@iro.umontreal.ca>, 23...@debbugs.gnu.org, 
>> rpl...@gmail.com, jwieg...@gmail.com, nljlistb...@gmail.com
>> 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
  ;; Save and restore the match data, as recommended in (elisp)Change Hooks
    (when flycheck-mode
      ;; The buffer was changed, thus clear the idle 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

However it doesn't look as though it tweaks the buffer until idle timer
has run. Weird....

Alex Bennée

Reply via email to