From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii Subject: =?UTF-8?B?YnVnIzIzOTE3OiBQbGVhc2UgY29uc2lkZXIgbWFraW5nIEJ1ZyAj?= =?UTF-8?B?MjM5MTcgYSBibG9ja2VyIGZvciAyNS4xICh3YXMgUmU6IG9yZy1jYXB0dXJl?= =?UTF-8?B?OiBDYXB0dXJlIHRlbXBsYXRlIOKAmGfigJk6IE1hdGNoIGRhdGEgY2xvYmJl?= =?UTF-8?B?cmVkIGJ5IGJ1ZmZlciBtb2RpZmljYXRpb24gaG9va3Mp?= Date: Wed, 20 Jul 2016 17:55:11 +0300 Message-ID: <83shv4z7e8.fsf__3306.31501642547$1469026634$gmane$org@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> Reply-To: Eli Zaretskii 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]:33307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPsuu-000599-1G for emacs-orgmode@gnu.org; Wed, 20 Jul 2016 10:56:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPsut-0008VT-4l for emacs-orgmode@gnu.org; Wed, 20 Jul 2016 10:56:08 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: (message from Stefan Monnier on Tue, 19 Jul 2016 21:50:07 -0400) 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: Stefan Monnier Cc: nljlistbox2@gmail.com, npostavs@users.sourceforge.net, jwiegley@gmail.com, rpluim@gmail.com, 23917@debbugs.gnu.org, alex.bennee@linaro.org > From: Stefan Monnier > Cc: rpluim@gmail.com, 23917@debbugs.gnu.org, alex.bennee@linaro.org, jwiegley@gmail.com, nljlistbox2@gmail.com > Date: Tue, 19 Jul 2016 21:50:07 -0400 > > > 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. What about Noam's suggestion: > Is it not possible to adjust the match data *before* calling buffer > modification hooks? Seems to me the root of the problem is that buffer > modification hooks get to see this invalid intermediate state where the > match data is out of sync with the buffer. 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?