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

[Robert Pluim <rpluim@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> Run Emacs under a debugger, and set a breakpoint before the call to
> replace_range in Freplace_match.  When the breakpoint breaks, make
> sure it's indeed being called from org-capture-empty-lines-after, and
> if so, do this:
>
>   (gdb) watch -l search_regs.start[sub]
>   (gdb) watch -l search_regs.end[sub]
>   (gdb) watch -l search_regs.num_regs
>   (gdb) continue
>
> Then GDB will kick in as soon as one of these 3 is clobbered, and the
> backtrace will show you whodunit.

So that gives me (after recompiling with -O0 -g3 :-) )

Hardware watchpoint 6: -location search_regs.end[sub]

Old value = 77
New value = 76
Fset_match_data (list=33497827, reseat=19440) at search.c:3010
3010		    if (!NILP (reseat) && MARKERP (m))

Lisp Backtrace:
"set-match-data" (0xffff9ad0)
0x1f6e8b0 PVEC_COMPILED
"org-element--cache-after-change" (0xffffa6c8)
"replace-match" (0xffffaa20)
"org-capture-empty-lines-after" (0xffffaf60)
"org-capture-place-entry" (0xffffb4b0)
"org-capture-place-template" (0xffffba00)
"org-capture" (0xffffc0b0)
"funcall-interactively" (0xffffc0a8)
"call-interactively" (0xffffc3e0)
"command-execute" (0xffffc968)
"execute-extended-command" (0xffffcfd0)
"funcall-interactively" (0xffffcfc8)
"call-interactively" (0xffffd360)
"command-execute" (0xffffd8c8)
(gdb) c
Continuing.

Breakpoint 4, Freplace_match (newtext=9563044, fixedcase=0, literal=0, string=0, subexp=0) at search.c:2710
2710	    error ("Match data clobbered by buffer modification hooks");

org-element--cache-after-change is:

(defun org-element--cache-after-change (beg end pre)
  "Update buffer modifications for current buffer.
BEG and END are the beginning and end of the range of changed
text, and the length in bytes of the pre-change text replaced by
that range.  See `after-change-functions' for more information."
  (when (org-element--cache-active-p)
    (org-with-wide-buffer
     (goto-char beg)
     (beginning-of-line)
     (save-match-data
       (let ((top (point))
	     (bottom (save-excursion (goto-char end) (line-end-position))))
	 ;; Determine if modified area needs to be extended, according
	 ;; to both previous and current state.  We make a special
	 ;; case for headline editing: if a headline is modified but
	 ;; not removed, do not extend.
	 (when (case org-element--cache-change-warning
		 ((t) t)
		 (headline
		  (not (and (org-with-limited-levels (org-at-heading-p))
			    (= (line-end-position) bottom))))
		 (otherwise
		  (let ((case-fold-search t))
		    (re-search-forward
		     org-element--cache-sensitive-re bottom t))))
	   ;; Effectively extend modified area.
	   (org-with-limited-levels
	    (setq top (progn (goto-char top)
			     (when (outline-previous-heading) (forward-line))
			     (point)))
	    (setq bottom (progn (goto-char bottom)
				(if (outline-next-heading) (1- (point))
				  (point))))))
	 ;; Store synchronization request.
	 (let ((offset (- end beg pre)))
	   (org-element--cache-submit-request top (- bottom offset) offset)))))
    ;; Activate a timer to process the request during idle time.
    (org-element--cache-set-timer (current-buffer))))

which already does save-match-data. If I globally disable the org
element cache by (setq org-element-use-cache nil) the issue
disappears, so now I'm confused as to what's going on.