> 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
