From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii 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: Wed, 20 Jul 2016 21:55:29 +0300 Message-ID: <83inw0yw9q.fsf@gnu.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> <83shv4z7e8.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1469041049 20510 80.91.229.3 (20 Jul 2016 18:57:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Jul 2016 18:57:29 +0000 (UTC) Cc: nljlistbox2@gmail.com, npostavs@users.sourceforge.net, jwiegley@gmail.com, rpluim@gmail.com, 23917@debbugs.gnu.org, alex.bennee@linaro.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 20 20:57:19 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 1bPwgJ-0002CX-1H for geb-bug-gnu-emacs@m.gmane.org; Wed, 20 Jul 2016 20:57:19 +0200 Original-Received: from localhost ([::1]:36486 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPwgH-0007PE-W7 for geb-bug-gnu-emacs@m.gmane.org; Wed, 20 Jul 2016 14:57:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPwg5-0007N2-Sb for bug-gnu-emacs@gnu.org; Wed, 20 Jul 2016 14:57:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPwg1-0001O2-WE for bug-gnu-emacs@gnu.org; Wed, 20 Jul 2016 14:57:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46591) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPwg1-0001Nt-ST; Wed, 20 Jul 2016 14:57:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bPwg1-0002nW-LG; Wed, 20 Jul 2016 14:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Wed, 20 Jul 2016 18:57: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.146904096510684 (code B ref 23917); Wed, 20 Jul 2016 18:57:01 +0000 Original-Received: (at 23917) by debbugs.gnu.org; 20 Jul 2016 18:56:05 +0000 Original-Received: from localhost ([127.0.0.1]:58928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bPwf7-0002mF-0b for submit@debbugs.gnu.org; Wed, 20 Jul 2016 14:56:05 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bPwf4-0002li-Uv for 23917@debbugs.gnu.org; Wed, 20 Jul 2016 14:56:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPwey-0000mq-FB for 23917@debbugs.gnu.org; Wed, 20 Jul 2016 14:55:57 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPwee-0000Wz-ND; Wed, 20 Jul 2016 14:55:36 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4439 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bPweb-0001zN-14; Wed, 20 Jul 2016 14:55:35 -0400 In-reply-to: (message from Stefan Monnier on Wed, 20 Jul 2016 14:19:59 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:121328 Archived-At: > From: Stefan Monnier > Cc: rpluim@gmail.com, 23917@debbugs.gnu.org, alex.bennee@linaro.org, jwiegley@gmail.com, nljlistbox2@gmail.com, npostavs@users.sourceforge.net > Date: Wed, 20 Jul 2016 14:19:59 -0400 > > > Is it OK to adjust the match data before actually making the > > replacement? If so, I think it's a simpler solution. > >> 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. > > Isn't that almost the same as what Noam suggested? > > Yes, it's the same. And yes, I like the idea, but I just don't know > what it would look like as a patch. I have the impression that it could > prove either expensive in CPU time and backward incompatible > (e.g. adjust markers for every buffer modification), or require > extensive code surgery and/or breaking some abstractions. > > This is just an impression, tho. I think it'd definitely be the better > solution, so it's worth investigating anyway, if only for "master" rather > than for "emacs-25". Maybe there's a misunderstanding. What Noam suggested was just to move the code which adjusts search_regs.start[i] and .end[i] to before the call to replace_range. The above values are not markers, and no other markers are involved, so I'm not sure which markers did you allude to. Or why it would be CPU intensive. What did I miss?