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: Tue, 19 Jul 2016 18:36:08 +0300 Message-ID: <838twx1vyv.fsf@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> <83lh0y24y6.fsf@gnu.org> 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]:54244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPX50-0002KS-F3 for emacs-orgmode@gnu.org; Tue, 19 Jul 2016 11:37:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPX4w-0008BL-ON for emacs-orgmode@gnu.org; Tue, 19 Jul 2016 11:37:06 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: (message from Stefan Monnier on Mon, 18 Jul 2016 20:58:35 -0400) 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: Stefan Monnier Cc: 23917@debbugs.gnu.org, rpluim@gmail.com, jwiegley@gmail.com, alex.bennee@linaro.org, nljlistbox2@gmail.com > From: Stefan Monnier > Cc: Robert Pluim , 23917@debbugs.gnu.org, alex.bennee@linaro.org, jwiegley@gmail.com, nljlistbox2@gmail.com > Date: Mon, 18 Jul 2016 20:58:35 -0400 > > > I think this change performed by save-match-data is harmless: the old > > value (62) was not valid any more anyway. > > In this particular case, yes. But only in this case, because (a) > there's actually only one sub-expression, and (b) it ends exactly at > EOB. Moreover, if the value of 62 was left alone by save-match-data, the adjustment code in replace-match would have fixed it. That's what that code is all about: it fixes the match data due to changes to the buffer made by replacing the old text by the new. Any attempts to "fix" those values under that code's feet are not helpful; quite the contrary. > > 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. > > And lose the other sub-expressions in a more general case? Really? What really bothers me is that by just loosening the conditions under which we signal an error we defeat _valid_ code, which did use save-match-data, and yet the match data still ends up being clobbered. I don't mind making the test more loose so that invalid programs have a longer rope to hang themselves, but valid programs should not be failed, IMO. > > Or maybe instead of signaling an error, we could simply skip the "Adjust > > search data for this change". > That would still sweep the problem under the carpet, leaving the match > data bogus, so I don't like doing that. > > 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. > The crash in bug#23869 was due to this: > newpoint = search_regs.start[sub] + SCHARS (newtext); > [...] > /* Now move point "officially" to the start of the inserted replacement. */ > move_if_not_intangible (newpoint); <<<<<<<<<<<<<<<<<<<<<<< > because due to clobbering, newpoint became -1. > > > - '((save-match-data-internal (match-data))) > > > + '((save-match-data-internal (match-data 'integers))) > > > > That looks risky. > > Then how about manually doing the equivalent of save-match-data around > the call to replace_range, calling match-data with non-nil argument? Here are some more alternatives for dealing with this issue: (1) Make match-data use integers instead of markers by default when a call to replace-match is in progress, i.e. when match-data is called from some buffer-modification hook triggered by replace-match (2) Don't signal an error, even if match data seems clobbered, if the new value of point is valid and either (a) there's only one search register, or (b) the adjustment value is zero (i.e. the registers will be left unchanged). I like (1) better than (2) because (1) will let valid programs avoid clobbering match data, but maybe it's too risky for emacs-25. Also, is it plausible that some buffer-modification hook will edit the buffer in the save-match-data forms, and expect the match data to be adjusted, or is this something that a buffer-modification hook should never do? If valid programs can do this, then (1) is probably not a good idea.