That is a good explanation, Romano. Rebol's parse holds strong against my doubt.
Anton. > The problem is given by the interaction of remove with parse, but > it is not a > bug. > > At every match, parse remember the position at which the parsing process > arrived, in your example this position is exactly mark2. > > When you remove at least > > 1 + length? mark2 > > chars, starting from mark1, you put mark2 (and the internal parse position > index) beyond the end of the string, like happens in this simulation: > > mark1: "123" > mark2: next mark1 > remove/part mark1 1 + (length? mark2) > mark2 > == ** Script Error: Out of range or past end > > When parse restarts, it check its internal index position and sees it is > beyond the end of the string, so it stops and does not execute your :mark1 > command. > > You must be sure that the position of parse is not beyond the end of the > string. > > You can do something like this to fix the problem: > > html rule: [ > any [ > (print "~~~ any block ~~~") > to "<script" mark1: (?? mark1) > thru "/script>" mark2: > :mark1 ;go back to mark1 before removing chars > ( ?? mark2 > remove/part mark1 mark2 > ?? mark1 > ) > (?? mark1) > ] to end > ] > > In our example we put the parse internal position index to the > mark1 position > before removing chars and not after. So we can be sure not to > invalidate the > internal position index of parse. > > --- > Ciao > Romano -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
