GNU bug report logs -
#23917
25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out
Previous Next
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: 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.