[O] bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out

[N. Jackson]

At 10:08 +0200 on Thursday 2016-07-21, Robert Pluim wrote:
>>
> address@hidden (N. Jackson) writes:
>
>> At 21:09 +0300 on Monday 2016-07-18, Eli Zaretskii wrote:
>>
>>> diff --git a/lisp/subr.el b/lisp/subr.el
>>> index e9e19d3..1bb1cb3 100644
>>> --- a/lisp/subr.el
>>> +++ b/lisp/subr.el
>>> @@ -3466,7 +3466,7 @@ save-match-data
>>>    ;; if you need to recompile all the Lisp files using interpreted code.
>>>    (declare (indent 0) (debug t))
>>>    (list 'let
>>> -   '((save-match-data-internal (match-data)))
>>> +   '((save-match-data-internal (match-data 'integers)))
>>>     (list 'unwind-protect
>>>           (cons 'progn body)
>>>           ;; It is safe to free (evaporate) markers immediately here,
>>
>> FWIW on my system applying this patch does not resolve the org-capture
>> issue. I'm testing with org-20160718 from GNU Elpa and latest Emacs 25
>> branch from the git (Repository revision: 
>> 4157159a37b43712440da91a45a6d5f71eb96e8a).
>
> save-match-data is a macro. Did you recompile org with the modified
> emacs?

Thanks Robert. I failed to take that into account.

After re-applying Eli's patch above and then rebuilding Org Mode from
GNU Elpa (now org-20160719), the org-capture match-data-clobbered
error/abort no longer occurs, neither with the simple recipe in emacs -Q
nor with my own capture templates with my full config loaded.

Sorry for the noise.

[For completeness, I should say that I then removed the patch and
rebuilt org-20160719 again, and confirmed that it does trigger the bug
in both emacs -Q and with my configuration.]

N.