From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex =?UTF-8?Q?Benn=C3=A9e?= Subject: =?UTF-8?B?YnVnIzIzOTE3OiAgYnVnIzIzOTE3OiBQbGVhc2UgY29uc2lkZXIg?= =?UTF-8?B?bWFraW5nIEJ1ZyAjMjM5MTcgYSBibG9ja2VyIGZvciAyNS4xICh3YXMgUmU6?= =?UTF-8?B?IG9yZy1jYXB0dXJlOiBDYXB0dXJlIHRlbXBsYXRlIOKAmGfigJk6IE1hdGNo?= =?UTF-8?B?IGRhdGEgY2xvYmJlcmVkIGJ5IGJ1ZmZlciBtb2RpZmljYXRpb24gaG9va3Mp?= Date: Tue, 19 Jul 2016 18:45:44 +0100 Message-ID: <878twxmshj.fsf__4620.84367541156$1468952351$gmane$org@linaro.org> References: <87vb066ejv.fsf@linaro.org> <8360s67qcp.fsf@gnu.org> <87bn1yyaui.fsf@linaro.org> <87mvlhmv0x.fsf_-_@moondust.awandering> <837fcl5zs9.fsf@gnu.org> <87a8hgkwcb.fsf@linaro.org> <8360s42mcb.fsf@gnu.org> <87eg6rgmlg.fsf@gmail.com> <83lh0y24y6.fsf@gnu.org> <83eg6q1hbo.fsf@gnu.org> <83a8hd1vzi.fsf@gnu.org> <834m7l1u8u.fsf@gnu.org> <87a8hdmuce.fsf@linaro.org> <8337n51r4f.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPZ5t-0002t5-U4 for emacs-orgmode@gnu.org; Tue, 19 Jul 2016 13:46:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPZ5r-0008Ns-PW for emacs-orgmode@gnu.org; Tue, 19 Jul 2016 13:46:08 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <8337n51r4f.fsf@gnu.org> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Eli Zaretskii Cc: nljlistbox2@gmail.com, jwiegley@gmail.com, rpluim@gmail.com, me@lunaryorn.com, 23917@debbugs.gnu.org, monnier@iro.umontreal.ca Eli Zaretskii writes: >> From: Alex Bennée >> Cc: Stefan Monnier , 23917@debbugs.gnu.org, rpluim@gmail.com, jwiegley@gmail.com, nljlistbox2@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 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