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

Previous Next

Packages: org-mode, emacs;

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 #77 received at 23917 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23917 <at> debbugs.gnu.org, rpluim <at> gmail.com, alex.bennee <at> linaro.org,
 nljlistbox2 <at> gmail.com, jwiegley <at> gmail.com
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: 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.

> 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).




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.