From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Monnier Subject: =?UTF-8?B?YnVnIzIzOTE3OiBQbGVhc2UgY29uc2lkZXIgbWFraW5nIEJ1ZyAj?= =?UTF-8?B?MjM5MTcgYSBibG9ja2VyIGZvciAyNS4xICh3YXMgUmU6IG9yZy1jYXB0dXJl?= =?UTF-8?B?OiBDYXB0dXJlIHRlbXBsYXRlIOKAmGfigJk6IE1hdGNoIGRhdGEgY2xvYmJl?= =?UTF-8?B?cmVkIGJ5IGJ1ZmZlciBtb2RpZmljYXRpb24gaG9va3Mp?= Date: Mon, 18 Jul 2016 20:58:35 -0400 Message-ID: References: <87vb066ejv.fsf@linaro.org> <8360s67qcp.fsf@gnu.org> <87bn1yyaui.fsf@linaro.org> <87mvlhmv0x.fsf_-_@moondust.awandering> <837fcl5zs9.fsf@gnu.org> <87a8hgkwcb.fsf@linaro.org> <8360s42mcb.fsf@gnu.org> <87eg6rgmlg.fsf@gmail.com> <83lh0y24y6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57929) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPJNJ-0008AE-S9 for emacs-orgmode@gnu.org; Mon, 18 Jul 2016 20:59:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPJNF-00067F-Uh for emacs-orgmode@gnu.org; Mon, 18 Jul 2016 20:59:05 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <83lh0y24y6.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 18 Jul 2016 21:09:53 +0300") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Eli Zaretskii Cc: 23917@debbugs.gnu.org, Robert Pluim , jwiegley@gmail.com, alex.bennee@linaro.org, nljlistbox2@gmail.com > In the case in point, a single character at EOB (=3D 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 =E2=89=A5 EOB = gets changed to something else that's also =E2=89=A5 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