emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: npostavs@users.sourceforge.net
To: Eli Zaretskii <eliz@gnu.org>
Cc: nljlistbox2@gmail.com, jwiegley@gmail.com, rpluim@gmail.com,
	23917@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>,
	alex.bennee@linaro.org
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 19:18:36 -0400	[thread overview]
Message-ID: <87k2ghcj3n.fsf__7747.58281554586$1469522102$gmane$org@users.sourceforge.net> (raw)
In-Reply-To: <83a8hd1vzi.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Jul 2016 18:35:45 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> 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.

  parent reply	other threads:[~2016-07-19 23:19 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
     [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                             ` npostavs [this message]
2016-07-19 15:36                       ` 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  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='87k2ghcj3n.fsf__7747.58281554586$1469522102$gmane$org@users.sourceforge.net' \
    --to=npostavs@users.sourceforge.net \
    --cc=23917@debbugs.gnu.org \
    --cc=alex.bennee@linaro.org \
    --cc=eliz@gnu.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 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).