[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re:

From: Stefan Monnier
Subject: bug#23917: 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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

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


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]