From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii Subject: =?UTF-8?B?YnVnIzIzOTE3OiBQbGVhc2UgY29uc2lkZXIgbWFraW5nIEJ1ZyAj?= =?UTF-8?B?MjM5MTcgYSBibG9ja2VyIGZvciAyNS4xICh3YXMgUmU6IG9yZy1jYXB0dXJl?= =?UTF-8?B?OiBDYXB0dXJlIHRlbXBsYXRlIOKAmGfigJk6IE1hdGNoIGRhdGEgY2xvYmJl?= =?UTF-8?B?cmVkIGJ5IGJ1ZmZlciBtb2RpZmljYXRpb24gaG9va3Mp?= Date: Mon, 18 Jul 2016 21:09:53 +0300 Message-ID: <83lh0y24y6.fsf__47424.3592507721$1468865525$gmane$org@gnu.org> 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> Reply-To: Eli Zaretskii Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPD0U-0007x9-Ep for emacs-orgmode@gnu.org; Mon, 18 Jul 2016 14:11:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPD0P-0007UD-T2 for emacs-orgmode@gnu.org; Mon, 18 Jul 2016 14:11:05 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87eg6rgmlg.fsf@gmail.com> (message from Robert Pluim on Mon, 18 Jul 2016 14:24:59 +0200) 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: Robert Pluim , Stefan Monnier Cc: 23917@debbugs.gnu.org, jwiegley@gmail.com, alex.bennee@linaro.org, nljlistbox2@gmail.com > From: Robert Pluim > CC: 23917@debbugs.gnu.org, Alex Bennée > , jwiegley@gmail.com, nljlistbox2@gmail.com > Date: Mon, 18 Jul 2016 14:24:59 +0200 > > (I'm moving this discussion to the bug, let me know if that's not OK) Thanks. > Make sure that you have org-20160704 from elpa. > > # emacs -Q > > ;evaluate the following > (custom-set-variables > '(package-selected-packages > (quote > (org-20160704)))) > (package-initialize) > > ; Now do: > > C-x C-f ~/.notes > M-x org-mode > M-x org-capture > t > > ; This should result in: > Capture template ‘t’: Match data clobbered by buffer modification > hooks Thanks again. It turns out the validation added in 3a9d6296, to solve bug#23869, exposed a very serious bug we seem to have always had with save-match-data called from buffer-modification hooks. The basic problem is that set-marker restricts the buffer position passed as its argument to valid limits, between 1 and EOB. So if you call set-marker with a value beyond EOB, the marker's position will silently set to EOB. Now, when buffer-modification hooks run due to changes made by replace-match, the replacement has already been done. If that replacement shrinks the buffer, then when save-match-data is called, and calls match-data, the latter will see the new (smaller) value of EOB. By default, match-data records the data in markers it creates for beginning and end of each matched sub-expression. So the result is that beginning and/or end of any sub-expression that was beyond the new EOB will be recorded as EOB. Then restoring this saved match data will clobber the data of those sub-expressions. 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. My suggestion to fix this is below. I ask for opinions on (1) whether this looks like TRT, (2) whether it is safe enough for emacs-25, and (3) whether someone has better ideas. If someone thinks I've misunderstood the issue, don't hesitate to explain why, because frankly it feels very strange to find bugs that seem to have existed since 1990. diff --git a/lisp/subr.el b/lisp/subr.el index e9e19d3..1bb1cb3 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -3466,7 +3466,7 @@ save-match-data ;; if you need to recompile all the Lisp files using interpreted code. (declare (indent 0) (debug t)) (list 'let - '((save-match-data-internal (match-data))) + '((save-match-data-internal (match-data 'integers))) (list 'unwind-protect (cons 'progn body) ;; It is safe to free (evaporate) markers immediately here,