> 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