From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eli Zaretskii <eliz@gnu.org>
Subject: bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8
 causing org-capture to error out
Date: Fri, 15 Jul 2016 22:46:42 +0300
Message-ID: <83y45265wd.fsf__34699.8452362188$1468630524$gmane$org@gnu.org>
References: <8760sgnvxh.fsf@gmail.com> <83lh1ci5x5.fsf@gnu.org>
	<87poqo6sud.fsf@gmail.com> <83a8hshxjs.fsf@gnu.org>
Reply-To: Eli Zaretskii <eliz@gnu.org>
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46488)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1bO95l-0001OS-JR
	for emacs-orgmode@gnu.org; Fri, 15 Jul 2016 15:48:10 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1bO95j-0007pr-O3
	for emacs-orgmode@gnu.org; Fri, 15 Jul 2016 15:48:08 -0400
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-Message-ID: <handler.23917.B23917.146861202531290@debbugs.gnu.org>
In-reply-to: <83a8hshxjs.fsf@gnu.org> (message from Eli Zaretskii on Fri, 08
	Jul 2016 20:03:35 +0300)
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode/>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: "Emacs-orgmode"
	<emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
To: rpluim@gmail.com
Cc: 23917@debbugs.gnu.org

> Date: Fri, 08 Jul 2016 20:03:35 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 23917@debbugs.gnu.org
> 
> > 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.
> 
> Load the file where this function lives as a .el file, and when the
> watchpoint triggers, show the results of "xbacktrace".

Actually, we might be looking in the wrong direction: since some of
these functions do use save-match-data, the search registers might be
legitimately changed and restored several times.  So I think you need
to type "continue" and see what other parts of code change the match
data, all the way until the call to replace_range returns.  Once we've
seen all those changes, with backtraces for each of them, we will
probably see the culprit.

It is still advisable to load the involved files as *.el files, as the
results of "xbacktrace" will then be more detailed.

Thanks.