World: r3wp

Yup. The ticket needs to be made either way. If it is rejected it 
will serve as documentation of the issue.

It can cause problems with backtracking though
 - actually, it can't, as can be demonstrated easily

(when implemented properly, of course)

Submitted as #1787, with the "when implemented properly" workarounds 
that Ladislav was mentioning. Note: Just because there is a solution 
to a problem doesn't make it not a problem - it just makes it a problem 
that can be solved.

aha, so, now the get-words can set parse to a different series (INTO 
does that as well!), but, what is restored, is just the index, not 
the series... (except for the return from INTO, when the series is 
restored as well

Yup. A half-solution, but we have workarounds for the other half 
:)

One interesting thing is that you can switch from string to block 
parsing and back mid-rule using series switching :)

Well, since it has been solved for INTO, it should suffice to use 
the already existing INTO solution

Yup, that would be preferred. And please mention that in a ticket 
comment to #1787 :)

Otherwise I will mention this in a comment and attribute the idea 
to you :)

so, Oldes, you should try this, which should be the exact equivalent 
of your rule, except for the fact, that it does not call Parse recursively:

some [
    thru {<h2><a} thru ">" copy name to {<}
    ; copy the DOC
    copy doc to {^/ </div>}
	; remember the DOC-END
	doc-end:
	; switch to DOC parsing
	:doc
    thru {<pre class="code">} copy code to {</pre} (
        probe name
        probe code
	)
    any [
        thru {<h5>} copy arg to {<}
        thru {<ol><p>} copy arg-desc to {</p></ol>}
        (printf ["  * " 10 " - "] reduce [arg arg-desc])
    ]
    ; switch to original input
    :doc-end
]

Thanks, Ladislav :)

Submitted as #1787, with the 

when implemented properly" workarounds that Ladislav was mentioning. 
Note: Just because there is a solution to a problem doesn't make 
it not a problem - it just makes it a problem that can be solved."


Geez, I'm not a Sissy ,But I pointed the workaround  from the beginning. 
Sometimes I just have the weird feeling I'm not trusted enough.
Sorry, I stop the whinning now :-)

Yes, Steeve, I know, that this has been discussed a while ago. Nevertheless, 
it is worth the effort to have it in a comment to the ticket.

(does not matter much to me who puts it in, though)

I just wanted to make sure to point at INTO, since it is already 
implemented, and working fine.

(and doing the same thing, at least in principle)

Yes, and a good point it was too.

Steeve, I'm sure that the reason it was so easy for me to come up 
with workarounds off the top of my head on a weak-brain day was because 
I had seen them before when you pointed them out and didn't remember 
it directly. In any case, I'm sure your stuff was great.

The ticket was for documentation purposes, as well as a request. 
It was to summarize the conversation from before.

Steeve, Ladislav... sorry, but your version is not working. The main 
SOME rule finds only one match and than stops. Maybe I should give 
you a simple test string so you could test it first.

hm.. it works on simple test, don't know why it stops for my real 
data.

that is interesting, (my version differs from Steeve's), but should 
be as similar to your version as possible

My simplified test is:
parse test: {[{1}{2}][{3}{4}][]} [
	some [
	    thru {[} 
	    ; copy the DOC
	    copy doc to {]}
		; remember the DOC-END
		doc-end:
		; switch to DOC parsing
		:doc
		(print "start")
		any [
			thru "{" copy n to "}" (probe n)
		]
	    ; switch to original input
	    (print "end")
	    :doc-end
	]
]
that's working as expected.

I understand the principe, but as I say, on real file it stops.

may be a Parse bug, e.g.

so, it is worth testing

What does "stops" mean, BTW?

you can test real data as well:)

print "loading data"
data: read/string http://www.imagemagick.org/api/magick-image.php
ask "parsing version 1"
parse/all data [
	some [
	    thru {<h2><a} thru ">" copy name to {<}
	    doc-start: to {^/ </div>} doc-end: :doc-start
		[
	        thru {<pre class="code">} copy code to {</pre} (
	            probe name
	            probe code
	        )
	        any [
	            thru {<h5>}
				here: if (lesser? index? here index? doc-end)
				copy arg to {<}
	            thru {<ol><p>} copy arg-desc to {</p></ol>}
	            (printf ["  * " 10 " - "] reduce [arg arg-desc])
	        ] 
	    ]
	    :doc-end
	]
]
ask "parsing version 2"
parse/all data [
	some [
	    thru {<h2><a} thru ">" copy name to {<}
	    ; copy the DOC
	    copy doc to {^/ </div>}
		; remember the DOC-END
		doc-end:
		; switch to DOC parsing
		:doc
	    thru {<pre class="code">} copy code to {</pre} (
	        probe name
	        probe code
		)
	    any [
	        thru {<h5>} copy arg to {<}
	        thru {<ol><p>} copy arg-desc to {</p></ol>}
	        (printf ["  * " 10 " - "] reduce [arg arg-desc])
	    ]
	    ; switch to original input
	    :doc-end
	]
]

aha, it needs to be written this way:

parse/all data [
	some [
	    thru {<h2><a} thru ">" copy name to {<}
	    ; copy the DOC
	    copy doc to {^/ </div>}
		; remember the DOC-END
		doc-end:
		; switch to DOC parsing
		; we need OPT to be able switch back
		:doc opt [
	        thru {<pre class="code">} copy code to {</pre} (
	            probe name
	            probe code
		    )
		    any [
		        thru {<h5>} copy arg to {<}
		        thru {<ol><p>} copy arg-desc to {</p></ol>}
		        (printf ["  * " 10 " - "] reduce [arg arg-desc])
		    ]
		]
	    ; switch to original input
	    :doc-end
	]
]

since OPT was needed, it is provable, that the "inner parse" fails 
sometimes, which does not look desirable, and may provoke your attention, 
Oldes

I've got it.. there is missing <pre> in the third doc so that's why 
Steeve's version fails.

(I wonder what they use to document the ImageMagick project.. it 
does not look like fully automated documentation. There are also 
some typos in the spec names.)

I'm working on an incremental lexer able to perform line-by-line 
analysis of any plain text documents.

the idea is to allow editing without having to reparse all the document.

The syntactical rules will be regular parse rules easy to understand 
and to modify, to facilitate
the creation of different model of document.

Of course, the first target is a rebol parser, but the make-doc format 
is also in my short range.

If anyone already have deep thoughts about the subject, please share 
your opinions.
I will come with a proto soon enough.

Will the REBOL parser be using the R3 incremental parser, TRANSCODE 
?

Btw, if you are using PARSE for incremental parsing, watch out for 
this: http://issue.cc/r3/1787

what is the equivalent in R3  of disarm ?

Nothing, it's unnecessary in R3.

You have to DO an error explicitly to trigger it. Otherwise, you 
can just reference it directly as if it were an object.

value: disarm :value 
 how i translate that ?

you  don't need to, just use the /error refinemeent with transcode.
>> transcode/next/error
and you get an error object if any

[!REBOL3 Parse group now exists for specific R3 Parse discussions]

ok thx

steeve it's in the colorize function code of area tc ...

either error? :value [
                        value: disarm :value

how do I adapt that ?

value: disarm :value 
Just get rid of the line.

ok ...

and this how i use transcode in it ? instead of load/next here ? 
>> error? set/any [value end] try [load/next start]

Shad, I will do it if you wait a little