From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template =?UTF-8?Q?=E2=80=98g=E2=80=99:?= Match data clobbered by buffer modification hooks) Date: Tue, 19 Jul 2016 21:50:07 -0400 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468979487 18223 80.91.229.3 (20 Jul 2016 01:51:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Jul 2016 01:51:27 +0000 (UTC) Cc: 23917@debbugs.gnu.org, rpluim@gmail.com, jwiegley@gmail.com, alex.bennee@linaro.org, nljlistbox2@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 20 03:51:16 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bPgfL-00015b-Ad for geb-bug-gnu-emacs@m.gmane.org; Wed, 20 Jul 2016 03:51:15 +0200 Original-Received: from localhost ([::1]:60011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPgfK-0008DX-Li for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Jul 2016 21:51:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPgfB-0008Cd-FA for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2016 21:51:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPgf8-0001EX-9X for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2016 21:51:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45406) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPgf8-0001ET-5f; Tue, 19 Jul 2016 21:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bPgf7-0003Xd-TG; Tue, 19 Jul 2016 21:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Wed, 20 Jul 2016 01:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23917 X-GNU-PR-Package: emacs,org-mode X-GNU-PR-Keywords: Original-Received: via spool by 23917-submit@debbugs.gnu.org id=B23917.146897941513558 (code B ref 23917); Wed, 20 Jul 2016 01:51:01 +0000 Original-Received: (at 23917) by debbugs.gnu.org; 20 Jul 2016 01:50:15 +0000 Original-Received: from localhost ([127.0.0.1]:57743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bPgeN-0003Wb-KE for submit@debbugs.gnu.org; Tue, 19 Jul 2016 21:50:15 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:22734) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bPgeL-0003WN-KN for 23917@debbugs.gnu.org; Tue, 19 Jul 2016 21:50:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtDgA731xV/3mcpUVcgxCEAgjIWAICAQECgTw9EAEBAQEBAQGBCkEFg10BAQMBDEojBQsJAjQHCxQYDRMRiDcIjXzBJwEBCAIBH4o4gQKFBQeELQWfF4NrkD2BRSOCO4FZIoJ4AQEB X-IPAS-Result: A0CtDgA731xV/3mcpUVcgxCEAgjIWAICAQECgTw9EAEBAQEBAQGBCkEFg10BAQMBDEojBQsJAjQHCxQYDRMRiDcIjXzBJwEBCAIBH4o4gQKFBQeELQWfF4NrkD2BRSOCO4FZIoJ4AQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="248602596" Original-Received: from 69-165-156-121.dsl.teksavvy.com (HELO pastel.home) ([69.165.156.121]) by ironport2-out.teksavvy.com with ESMTP; 19 Jul 2016 21:50:09 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id B001464CD0; Tue, 19 Jul 2016 21:50:07 -0400 (EDT) In-Reply-To: <834m7l1u8u.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Jul 2016 19:13:21 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:121282 Archived-At: > Do we care that using save-match-data in every call to replace-match > might mean a performance hit? I do but: - to be honest, it's probably lost in the noise. - if we copy search_regs.start and search_regs.end with something like alloca+memcpy (instead of calling Fmatch_data), the cost should be even more lost in the noise. Especially if you consider that the current code already loops through the match-data to adjust it. - it's the best fix we've found so far. > 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 think the combination of 1 and 2 is actually pretty frequent. Stefan PS: I can think of one (theoretical) other/better way to fix this problem: move the match-data adjustment so it's done within replace_range before running the after-change-functions. I think this would be very satisfactory, since it would mean that the Elisp code would always see the valid match-data (whereas currently the after-change-functions get passed not-yet-adjusted match-data), so save-match-data wouldn't mess it up. But I fear this would require much larger changes (and might involve a heavier performance cost as well).