World: r3wp

if you want the RSP line on a separte line from the '{', then put 
a  the word   newline   before the string "RSP: ", or use  "^/RSP: 
", where the   "^/" is equivalent to a newline or carriage return.

with the result...
Cmd:  {if error? try [1 + "x"] [print "Did not work."]
}
RSP:  "Did not work."

if you want to capture multiple command and response blocks you wrap 
the parse block in...
any[ parse statements] 

.... excluding the to end statement which you would want to include 
only after   'any'   parse instances occured.

parse page-txt [
	any[
		thru pre-bgn 
		copy cmd-txt 
		to rsp-bgn
		thru rsp-bgn
		copy rsp-term 
		to rsp-end 
		(print ["Cmd: " mold cmd-txt "^/RSP: " mold rsp-term])
	]
	to end
]

Excellent suggestions Brock and Graham -- That gives me a lot to 
play with!!  Thank you.

Does someone know of some scripts that parse documents written in 
LaTex.  I would need examples applying parse to the LaTex language.

What about parsing another similar language?

http://www.rebol.org/view-script.r?script=qml-base.r

This is ell written too http://www.codeconscious.com/rebol/parse-tutorial.html

Thanks for those references.

Parse question on StackOverflow -- not yet answered:

http://stackoverflow.com/questions/1415340/rebol-parsing-rule-how-to-correct-the-rule-to-separate-paragraphs

Three answers now.

Steeve - move parse discussion here.

So... does such a function take an argument, such as the current 
index for the series being parsed?

That's how REPLACE works...

REPLACE?

i would say, no functions with parameters allowed

but if you can perform a do/next then parameters are allowed

Yeah. If you pass a function as the replacement value, that function 
will be called with the series at the replacement position as a parameter, 
and its return value is used. ARRAY does something similar too. My 
changes.

Say that the series position parameter is passed with APPLY rules. 
If the function takes a parameter it sees it; if not it doesn't.

Or we can provide 2 index by default, maintained by the parse engine.
& = the head of last rule matched
&&= the tail of the last matched rule.

Not a bad idea, but... this is how it starts. This is what led to 
the rule! type suggestion :(

See, your method would allow REPLACE/part to be called directly.

Sorry, REMOVE/part.

or even INSERT, REMOVE, CHANGE, without the need to develop a specific 
inlinned method for those functions

wer just need 2 pointers auto-handled by parse

Except your replacement code for those functions was wrong. And would 
be wrong in this case. Those inline operations were added to reduce 
common errors, not to provide missing functionality.

I am also concerned about the security implications of having PARSE 
call functions outside of parens. In parens you know what you're 
getting. This is why QUOTE and IF require parens for the REBOL code 
they execute.

All of the added operations could have been done before with code 
in parens and/or explicit position setting. It's easier this way.

I put a note up because of my silly misunderstanding of the intent 
of adding AND to PARSE.  But I get odd results with the likes of 
   parse "abeabd" [and [thru "e"] [thru "d'"]]  which behaves like 
ANY

Not a silly misunderstanding, a bug, bug#1238 in particular.

One of 4 parse bugs in a83.

OF course in STSC APL  "laod" was as good as "load" and in Smalltalk 
I still long for "slef" and "sefl" but I draw the line at "elfs" 
which is clearly unfit in the age of "octopuses"

And that doesn't even count the stuff not implemented yet.

I thought ONE (but no move) on the model of SOME and ANY when I was 
misunderstanding AND as "all"  as [ ONE [rule1 rule2 rule3 ] ]

ONE would be an interesting name for the OF proposal.

Shorter than UNIQUE

Sorry, that would be a different operation.

Shorter than FROM or GATHER though.

Wait, ONE wouldn't work, since you actually get all of the rules, 
just not in order.

I posted examples to show why a84 is more rebolish. http://www.rebol.net/cgi-bin/r3blog.r?view=0255#comments

looks good ...

Steeve - will better parse help with editor? IIRC it was you and 
Shadwolf, who did it?

A little, but the main drawback i have with parsing in editor is 
that parse doesn't handle incremental parsing.

Because i do parsing line by line to be able to parse only modified 
lines.

So that, i have to rewrite all the rules (describing the document) 
in an obfuscated way to deal with incremental parsing.

BrianH has some plans towards "streamed" parsing. Hopefully it can 
be done over ports in the future ...

Actually, we can simulate streamed/incremental parsing. But we need 
to transform all the input rules (it can be automatized).
I would prefer an inlined behavior of parse for such purpose.

It's why i asked to Carl if we could return the rule stack during 
parsing (i.e. with a special command).

What was the answer? I missed your request during yesterday's chat 
probably ...

Request delayed for R3.1

3.1 - that will be in Spring, so I think that we can wait ...

it seems

parse is in mode parse/all by default now, but we can remove the 
option, a bug ?