|
From: | Stefan Monnier |
Subject: | [O] 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. 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).
[Prev in Thread] | Current Thread | [Next in Thread] |