From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 23917@debbugs.gnu.org, rpluim@gmail.com, jwiegley@gmail.com,
alex.bennee@linaro.org, nljlistbox2@gmail.com
Subject: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)
Date: Tue, 19 Jul 2016 05:40:11 +0300 [thread overview]
Message-ID: <83eg6q1hbo.fsf__43251.5168017291$1468896655$gmane$org@gnu.org> (raw)
In-Reply-To: <jwvmvle5udz.fsf-monnier+emacsbugs@gnu.org> (message from Stefan Monnier on Mon, 18 Jul 2016 20:58:35 -0400)
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Robert Pluim <rpluim@gmail.com>, 23917@debbugs.gnu.org, alex.bennee@linaro.org, jwiegley@gmail.com, nljlistbox2@gmail.com
> Date: Mon, 18 Jul 2016 20:58:35 -0400
>
> > 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.
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.
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,
should the buffer-modification hooks use save-match-data.
> 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?
> 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?
next prev parent reply other threads:[~2016-07-19 2:41 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-15 16:39 org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks Alex Bennée
2016-07-15 17:39 ` Eli Zaretskii
2016-07-15 19:12 ` Alex Bennée
2016-07-15 19:37 ` Noam Postavsky
2016-07-15 21:56 ` Alex Bennée
2016-07-16 16:01 ` Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks) N. Jackson
2016-07-16 16:11 ` Eli Zaretskii
2016-07-16 17:09 ` John Wiegley
2016-07-17 17:28 ` Alex Bennée
2016-07-17 17:41 ` Eli Zaretskii
2016-07-18 12:24 ` bug#23917: " Robert Pluim
2016-07-18 18:09 ` Eli Zaretskii
2016-07-18 18:09 ` Eli Zaretskii
2016-07-18 19:04 ` John Wiegley
2016-07-18 19:10 ` Eli Zaretskii
2016-07-18 19:10 ` Eli Zaretskii
2016-07-18 19:04 ` John Wiegley
2016-07-19 0:58 ` Stefan Monnier
2016-07-19 2:40 ` Eli Zaretskii
2016-07-19 4:48 ` Stefan Monnier
2016-07-19 15:35 ` Eli Zaretskii
2016-07-19 15:35 ` Eli Zaretskii
2016-07-19 16:03 ` Stefan Monnier
2016-07-19 16:03 ` Stefan Monnier
2016-07-19 16:13 ` Eli Zaretskii
2016-07-19 16:13 ` Eli Zaretskii
2016-07-19 17:05 ` bug#23917: [O] " Alex Bennée
2016-07-19 17:20 ` Eli Zaretskii
2016-07-19 17:45 ` Alex Bennée
2016-07-19 18:07 ` bug#23917: " Sebastian Wiesner
2016-07-19 18:07 ` bug#23917: [O] " Sebastian Wiesner
2016-07-19 18:44 ` bug#23917: " Eli Zaretskii
2016-07-20 9:48 ` bug#23917: " Alex Bennée
2016-07-20 9:48 ` bug#23917: [O] " Alex Bennée
2016-07-20 14:59 ` bug#23917: " Eli Zaretskii
2016-07-20 14:59 ` bug#23917: [O] " Eli Zaretskii
2016-07-19 18:44 ` bug#23917: [O] " Eli Zaretskii
2016-07-19 17:45 ` bug#23917: " Alex Bennée
2016-07-19 17:20 ` Eli Zaretskii
2016-07-19 17:05 ` Alex Bennée
2016-07-20 1:50 ` Stefan Monnier
2016-07-20 14:55 ` Eli Zaretskii
2016-07-20 14:55 ` Eli Zaretskii
2016-07-20 18:19 ` Stefan Monnier
2016-07-20 18:55 ` Eli Zaretskii
2016-07-20 20:54 ` Stefan Monnier
2016-07-20 20:54 ` Stefan Monnier
2016-07-21 0:56 ` npostavs
2016-07-21 1:47 ` Stefan Monnier
2016-07-21 2:34 ` Noam Postavsky
2016-07-21 2:34 ` Noam Postavsky
2016-07-21 3:06 ` Stefan Monnier
2016-07-21 3:06 ` Stefan Monnier
2016-07-21 1:47 ` Stefan Monnier
2016-07-21 2:43 ` Eli Zaretskii
2016-07-21 3:00 ` npostavs
2016-07-21 3:00 ` npostavs
2016-07-21 14:26 ` Eli Zaretskii
2016-07-22 1:08 ` npostavs
2016-07-22 1:08 ` npostavs
2016-07-22 6:43 ` Eli Zaretskii
2016-07-22 14:01 ` Robert Pluim
2016-07-22 14:01 ` Robert Pluim
2016-07-22 19:30 ` Nicolas Petton
2016-07-22 19:30 ` Nicolas Petton
2016-07-23 4:19 ` npostavs
2016-07-23 4:19 ` npostavs
2016-07-22 6:43 ` Eli Zaretskii
2016-07-23 0:42 ` bug#23917: Re: bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out N. Jackson
2016-07-23 0:42 ` N. Jackson
2016-07-23 7:38 ` Eli Zaretskii
2016-07-23 7:38 ` Eli Zaretskii
2016-07-21 14:26 ` bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks) Eli Zaretskii
2016-07-21 2:43 ` Eli Zaretskii
2016-07-21 7:59 ` bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out N. Jackson
2016-07-21 8:19 ` Robert Pluim
2016-07-21 8:19 ` Robert Pluim
2016-07-08 12:42 ` Robert Pluim
2016-07-08 14:02 ` Eli Zaretskii
2016-07-08 15:40 ` Robert Pluim
2016-07-08 17:03 ` Eli Zaretskii
2016-07-08 17:03 ` Eli Zaretskii
2016-07-15 19:46 ` Eli Zaretskii
2016-07-15 19:46 ` Eli Zaretskii
2016-07-21 14:24 ` N. Jackson
2016-07-21 14:24 ` N. Jackson
2016-07-21 7:59 ` N. Jackson
2016-07-21 0:56 ` bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks) npostavs
2016-07-20 18:55 ` Eli Zaretskii
2016-07-20 18:19 ` Stefan Monnier
2016-07-20 1:50 ` Stefan Monnier
2016-07-19 23:18 ` npostavs
2016-07-19 23:18 ` npostavs
2016-07-19 4:48 ` Stefan Monnier
2016-07-19 2:40 ` Eli Zaretskii [this message]
2016-07-19 15:36 ` Eli Zaretskii
2016-07-19 15:36 ` Eli Zaretskii
2016-07-19 0:58 ` Stefan Monnier
2016-07-21 7:52 ` bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out N. Jackson
2016-07-21 8:08 ` Robert Pluim
2016-07-21 8:08 ` Robert Pluim
2016-07-21 13:19 ` N. Jackson
2016-07-21 13:19 ` N. Jackson
2016-07-21 7:52 ` N. Jackson
2016-07-18 12:24 ` bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks) Robert Pluim
2016-07-18 14:50 ` Kaushal Modi
2016-07-18 14:50 ` Kaushal Modi
[not found] ` <9613abde4dbd48fdb2b5e780101a13a0@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2016-07-18 16:59 ` Eric S Fraga
2016-07-18 16:59 ` Eric S Fraga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='83eg6q1hbo.fsf__43251.5168017291$1468896655$gmane$org@gnu.org' \
--to=eliz@gnu.org \
--cc=23917@debbugs.gnu.org \
--cc=alex.bennee@linaro.org \
--cc=jwiegley@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=nljlistbox2@gmail.com \
--cc=rpluim@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.