GNU bug report logs - #23917
25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out

Previous Next

Packages: emacs, org-mode;

Reported by: Robert Pluim <rpluim <at> gmail.com>

Date: Fri, 8 Jul 2016 12:43:02 UTC

Severity: normal

Tags: fixed

Found in version 25.0.95

Fixed in version 25.1

Done: npostavs <at> users.sourceforge.net

Bug is archived. No further changes may be made.

Full log


Message #83 received at 23917 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: nljlistbox2 <at> gmail.com, npostavs <at> users.sourceforge.net, jwiegley <at> gmail.com,
 rpluim <at> gmail.com, 23917 <at> debbugs.gnu.org, alex.bennee <at> linaro.org
Subject: Re: Please consider making Bug #23917 a blocker for 25.1 (was Re:
 org-capture: Capture template ā€˜g’: Match data clobbered
 by buffer modification hooks)
Date: Wed, 20 Jul 2016 17:55:11 +0300
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: rpluim <at> gmail.com,  23917 <at> debbugs.gnu.org,  alex.bennee <at> linaro.org,  jwiegley <at> gmail.com,  nljlistbox2 <at> 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?




This bug report was last modified 8 years and 304 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.