GNU bug report logs - #23917
25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23917 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>, alex.bennee <at> linaro.org, nljlistbox2 <at> gmail.com, jwiegley <at> gmail.com
Subject: 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: Mon, 18 Jul 2016 20:58:35 -0400

> In the case in point, a single character at EOB (= 62) was deleted,
> which made EOB be 61, one less than its previous value.  When
> save-match-data was called from within a hook set up by Org, it tried
> to record the end of the sub-expression as 62, but set-marker silently
> changed that to 61.  That "corrected" value was subsequently restored
> when save-match-data was exited, whereas replace-match expected to see
> the original value of 62, and therefore barfed.

I think this change performed by save-match-data is harmless: the old
value (62) was not valid any more anyway.

So I think a safe fix is to try and relax the check we added to
replace-match so it doesn't get all worked up when something ≥ EOB gets
changed to something else that's also ≥ EOB.

Or maybe instead of signaling an error, we could simply skip the "Adjust
search data for this change".  I like the idea of signaling an error, as
a debugging help, but maybe for emacs-25 we should go for something less
intrusive after all?

This said, I don't fully understand what's going on: bug#23869 reported
a crash, but AFAICT the match-data here is only used to adjust
search_regs which seems like it wouldn't cause a crash, even if the new
values are bogus.  So maybe signaling an error is important because the
crash happens further down.

> -	'((save-match-data-internal (match-data)))
> +	'((save-match-data-internal (match-data 'integers)))

That looks risky.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.