[O] bug#23917: bug#23917: 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)

[Eli Zaretskii]

> From: Alex Bennée 
> Cc: 23...@debbugs.gnu.org, rpl...@gmail.com, jwieg...@gmail.com, 
> monn...@iro.umontreal.ca, nljlistb...@gmail.com
> Date: Wed, 20 Jul 2016 10:48:45 +0100
> 
> So is the match data already out of sync by the time the
> save-match-data call is made?

Yes.

[O] bug#23917: bug#23917: 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)

[Alex Bennée]

Eli Zaretskii  writes:

>> From: Alex Bennée 
>> Cc: monn...@iro.umontreal.ca, 23...@debbugs.gnu.org, rpl...@gmail.com, 
>> jwieg...@gmail.com, nljlistb...@gmail.com, m...@lunaryorn.com
>> Date: Tue, 19 Jul 2016 18:45:44 +0100
>>
>>   ;; Save and restore the match data, as recommended in (elisp)Change Hooks
>>   (save-match-data
>> (when flycheck-mode
>>   ;; The buffer was changed, thus clear the idle timer
>>   (flycheck-clear-idle-change-timer)
>>   (if (string-match-p (rx "\n") (buffer-substring beg end))
>>   (flycheck-buffer-automatically 'new-line 'force-deferred)
>> (setq flycheck-idle-change-timer
>>   (run-at-time flycheck-idle-change-delay nil
>>#'flycheck-handle-idle-change))
>>
>> However it doesn't look as though it tweaks the buffer until idle timer
>> has run. Weird
>
> Tweaking the buffer is not what causes the problem.  It's the call to
> save-match-data itself.  It doesn't matter at all what the code inside
> save-match-data does.

Ahh I misunderstood the description of the problem. I thought it was a
changing of the buffer underneath that meant the match data wasn't
updated and hence got out of sync. So is the match data already out of
sync by the time the save-match-data call is made?

--
Alex Bennée