From mboxrd@z Thu Jan 1 00:00:00 1970 From: npostavs@users.sourceforge.net Subject: =?UTF-8?B?YnVnIzIzOTE3OiBQbGVhc2UgY29uc2lkZXIgbWFraW5nIEJ1ZyAj?= =?UTF-8?B?MjM5MTcgYSBibG9ja2VyIGZvciAyNS4xICh3YXMgUmU6IG9yZy1jYXB0dXJl?= =?UTF-8?B?OiBDYXB0dXJlIHRlbXBsYXRlIOKAmGfigJk6IE1hdGNoIGRhdGEgY2xvYmJl?= =?UTF-8?B?cmVkIGJ5IGJ1ZmZlciBtb2RpZmljYXRpb24gaG9va3Mp?= Date: Tue, 19 Jul 2016 19:18:36 -0400 Message-ID: <87k2ghcj3n.fsf__7747.58281554586$1469522102$gmane$org@users.sourceforge.net> 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> <83eg6q1hbo.fsf@gnu.org> <83a8hd1vzi.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPeI9-0007Ap-Nv for emacs-orgmode@gnu.org; Tue, 19 Jul 2016 19:19:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPeI7-0006N4-FU for emacs-orgmode@gnu.org; Tue, 19 Jul 2016 19:19:08 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <83a8hd1vzi.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Jul 2016 18:35:45 +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: nljlistbox2@gmail.com, jwiegley@gmail.com, rpluim@gmail.com, 23917@debbugs.gnu.org, Stefan Monnier , alex.bennee@linaro.org Eli Zaretskii writes: >> From: Stefan Monnier >> Cc: rpluim@gmail.com, 23917@debbugs.gnu.org, alex.bennee@linaro.org, jwiegley@gmail.com, nljlistbox2@gmail.com >> Date: Tue, 19 Jul 2016 00:48:19 -0400 >> >> > The more general problem is when there's at least one more >> > sub-expression, whose start and/or end are after the new EOB. >> > Those sub-expression's data will be completely bogus after the >> > adjustment, >> >> If they were after the EOB, they were already bogus to start with. > > I think we are mis-communicating. I mean the following scenario: > > Before call to replace_range in replace-match: > > |---------------------------|---|------|----| > s1 e1 s2 e2 EOB > > (s1, e1, etc. are the start and end of the corresponding > sub-expressions.) > > After the call to replace_range in replace-match: > > |---------|---|------|----| > s1 e1 s2 e2 EOB > > IOW, the 1st sub-expression got replaced with a much shorter text, > which made EOB be smaller than the original beginning and end of the > 2nd sub-expression. There's nothing bogus with this, is there? The > user will expect to get match-data adjusted as shown in the second > diagram, and that's what she will really get -- unless there are > buffer-modification hooks that use save-match-data. In the latter > case, what the user will get instead is this: > > |---------|---|------|----| > s1 EOB > e1 > s2 > e2 > > and that is even before the adjustment code kicks in and makes > "adjustments" with an incorrect adjustment value, which is computed as > > newpoint = search_regs.start[sub] + SCHARS (newtext); > [...] > ptrdiff_t change = newpoint - search_regs.end[sub]; > > and so will use the new EOB as search_regs.end[sub], instead of the > correct original value of e1 from the first diagram above. > > IOW, the call to save-match-data in a buffer-modification hook > _disrupts_ the normal operation of replace-match in this case, by > indirectly sabotaging the adjustment of match data after the > replacement. Is it not possible to adjust the match data *before* calling buffer modification hooks? Seems to me the root of the problem is that buffer modification hooks get to see this invalid intermediate state where the match data is out of sync with the buffer.