From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
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 00:48:19 -0400 [thread overview]
Message-ID: <jwv1t2q5jsz.fsf-monnier+emacsbugs__46892.4161898487$1468903814$gmane$org@gnu.org> (raw)
In-Reply-To: <83eg6q1hbo.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Jul 2016 05:40:11 +0300")
> 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.
So there's really not much harm moving them around. And in any case,
that's what has been happening for ever and has proved safe enough.
>> 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?
I'm not sure what you mean by "losing sub-expressions". But yes,
I think the behavior of save-match-data you describe is not
a real problem. Arguably if save-match-data moves positions from
outside BEGV...ZV to inside it it's a problem. But if it moves them
from outside BEG...Z to inside it, I think it's perfectly fine.
>> 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.
Maybe I'm not 100% satisfied with the behavior either, but I don't think
it's a significant problem and I don't think it'd cause the crash we saw
in bug#23869.
> 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.
Ah, I see.
Then maybe another fix is to compute newpoint before we call
replace_range, so it uses search_regs.start[sub] before the
*-change-functions can mess it up. IOW:
@@ -2726,9 +2726,9 @@ since only regular expressions have distinguished subexpressions. */)
unsigned num_regs = search_regs.num_regs;
/* Replace the old text with the new in the cleanest possible way. */
+ newpoint = search_regs.start[sub] + SCHARS (newtext);
replace_range (search_regs.start[sub], search_regs.end[sub],
newtext, 1, 0, 1);
- newpoint = search_regs.start[sub] + SCHARS (newtext);
if (case_action == all_caps)
Fupcase_region (make_number (search_regs.start[sub]),
Would that be sufficient to avoid the crash? Why not?
Stefan
next prev parent reply other threads:[~2016-07-19 4:49 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87vb066ejv.fsf@linaro.org>
[not found] ` <8360s67qcp.fsf@gnu.org>
[not found] ` <87bn1yyaui.fsf@linaro.org>
[not found] ` <CAM-tV-9Befm+jtvvO9tZsYwCbzgggumNgWeuPzV-i=ZB0mgPog@mail.gmail.com>
[not found] ` <87mvlhmv0x.fsf_-_@moondust.awandering>
[not found] ` <837fcl5zs9.fsf@gnu.org>
[not found] ` <m28tx1o6h6.fsf@newartisans.com>
[not found] ` <87a8hgkwcb.fsf@linaro.org>
[not found] ` <8360s42mcb.fsf@gnu.org>
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
[not found] ` <9613abde4dbd48fdb2b5e780101a13a0@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2016-07-18 16:59 ` Eric S Fraga
[not found] ` <87eg6rgmlg.fsf@gmail.com>
2016-07-18 18:09 ` Eli Zaretskii
[not found] ` <83lh0y24y6.fsf@gnu.org>
2016-07-18 19:04 ` John Wiegley
2016-07-18 19:10 ` Eli Zaretskii
2016-07-19 0:58 ` Stefan Monnier
[not found] ` <jwvmvle5udz.fsf-monnier+emacsbugs@gnu.org>
2016-07-19 2:40 ` Eli Zaretskii
[not found] ` <83eg6q1hbo.fsf@gnu.org>
2016-07-19 4:48 ` Stefan Monnier [this message]
[not found] ` <jwv1t2q5jsz.fsf-monnier+emacsbugs@gnu.org>
2016-07-19 15:35 ` Eli Zaretskii
[not found] ` <83a8hd1vzi.fsf@gnu.org>
2016-07-19 16:03 ` Stefan Monnier
[not found] ` <jwvzipdeibv.fsf-monnier+emacsbugs@gnu.org>
2016-07-19 16:13 ` Eli Zaretskii
[not found] ` <834m7l1u8u.fsf@gnu.org>
2016-07-19 17:05 ` bug#23917: " Alex Bennée
[not found] ` <87a8hdmuce.fsf@linaro.org>
2016-07-19 17:20 ` Eli Zaretskii
[not found] ` <8337n51r4f.fsf@gnu.org>
2016-07-19 17:45 ` Alex Bennée
[not found] ` <878twxmshj.fsf@linaro.org>
2016-07-19 18:07 ` Sebastian Wiesner
2016-07-19 18:44 ` Eli Zaretskii
2016-07-20 9:48 ` bug#23917: " Alex Bennée
[not found] ` <877fcgmygy.fsf@linaro.org>
2016-07-20 14:59 ` Eli Zaretskii
2016-07-20 1:50 ` Stefan Monnier
[not found] ` <jwvd1m9dran.fsf-monnier+emacsbugs@gnu.org>
2016-07-20 14:55 ` Eli Zaretskii
[not found] ` <83shv4z7e8.fsf@gnu.org>
2016-07-20 18:19 ` Stefan Monnier
2016-07-20 18:55 ` Eli Zaretskii
[not found] ` <83inw0yw9q.fsf@gnu.org>
2016-07-20 20:54 ` Stefan Monnier
[not found] ` <jwvtwfkvxsc.fsf-monnier+emacsbugs@gnu.org>
2016-07-21 0:56 ` npostavs
[not found] ` <87bn1rdd1f.fsf@users.sourceforge.net>
2016-07-21 1:47 ` Stefan Monnier
[not found] ` <jwvzipb3gx0.fsf-monnier+emacsbugs@gnu.org>
2016-07-21 2:34 ` Noam Postavsky
[not found] ` <CAM-tV-9rqqOF=zjsXx3QQ5_z0n-fFB7-BCbxWdzb9EA_u2ZHPQ@mail.gmail.com>
2016-07-21 3:06 ` Stefan Monnier
2016-07-21 2:43 ` Eli Zaretskii
[not found] ` <83h9bjzp5i.fsf@gnu.org>
2016-07-21 3:00 ` npostavs
[not found] ` <877fcfd79w.fsf@users.sourceforge.net>
2016-07-21 14:26 ` Eli Zaretskii
[not found] ` <83a8hbysmw.fsf@gnu.org>
2016-07-22 1:08 ` npostavs
[not found] ` <874m7icwdg.fsf@users.sourceforge.net>
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
[not found] ` <83fur2xjeu.fsf@gnu.org>
2016-07-22 14:01 ` 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-22 19:30 ` Nicolas Petton
2016-07-23 4:19 ` npostavs
[not found] ` <878twtqj6n.fsf_-_@moondust.awandering>
2016-07-23 7:38 ` bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out Eli Zaretskii
2016-07-21 7:59 ` N. Jackson
[not found] ` <87a8hb2zgt.fsf_-___1286.15575745261$1469088239$gmane$org@moondust.awandering>
2016-07-21 8:19 ` Robert Pluim
[not found] ` <8760sgnvxh.fsf@gmail.com>
[not found] ` <83lh1ci5x5.fsf@gnu.org>
[not found] ` <87poqo6sud.fsf@gmail.com>
2016-07-08 17:03 ` Eli Zaretskii
[not found] ` <83a8hshxjs.fsf@gnu.org>
2016-07-15 19:46 ` Eli Zaretskii
2016-07-21 14:24 ` N. Jackson
2016-07-19 23:18 ` 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-19 15:36 ` Eli Zaretskii
2016-07-21 7:52 ` bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out N. Jackson
[not found] ` <87h9bj2zsl.fsf_-_@moondust.awandering>
2016-07-21 8:08 ` Robert Pluim
[not found] ` <87poq7xvjy.fsf@gmail.com>
2016-07-21 13:19 ` N. Jackson
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
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='jwv1t2q5jsz.fsf-monnier+emacsbugs__46892.4161898487$1468903814$gmane$org@gnu.org' \
--to=monnier@iro.umontreal.ca \
--cc=23917@debbugs.gnu.org \
--cc=alex.bennee@linaro.org \
--cc=eliz@gnu.org \
--cc=jwiegley@gmail.com \
--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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).