World: r3wp

that's thinked to render help documentation in your own GUI  software 
that's not thinked as a document writing tool. you have to use an 
external way to easyly create large formated documentation without 
having to keep in mind the over all markup language

Shadwolf, no, rich text in R3 is also writable. there was a bug a 
while ago that would let you unintentionally edit parts of the DOC 
style. We are just missing parts for logical control of the cursoe 
between different styles in the text and text selection across styles.

that's true of any layout engine.  if you look at pdf.. it actually 
doesnt include any text layout algorythms.. those must be built externally. 
 all pdf does is display vectors where you tell it to.

When I showed it to Carl, he was surprised it worked. :-)

maxim i already long time ago worked in the Markup document creation 
tools with ashley MDP-GUI  and one of the limitation was that you 
could not create the markup data and the at same time see the rendered 
result at same time you had to use 2 separated boxes one for rendering 
the other for "scripting the document"

R2 doesn't have any rich text you can direct.  which means you have 
to do all of the layout work manually.  as long as we have sizing 
examination of rich text atoms, then we can tell it to position things 
like we want and measure the result in order to properly convert 
the data to other formats.

yeah but anyway markup had another conversion stack wich would be 
better to be done directly to draw dialect. and i'm not sure the 
markup language doesn't imposible limitations that will not allow 
you to go out of the box.

i read the scrip it speak to draw directly hading the conversionn 
to markup layer since it's not thought for that purpose will had 
a delay to the engine. I really need to speak directly to draw. that's 
all

you must realize that the format  of a document (encoding of the 
layout) isn't directly  tied to its content.

basically the rich text dialect looks alot like what you are doing 
manually... all its missing is better analysis of its rendering results, 
IMHO.

it will be much faster, since much of the heavy lifting is done in 
binary rather than interpreted code.

as long as you can detect what word is under the cursor at a given 
 coordinate using specified scrolling, you could use the rich text 
directly.  and then output to whatever format you want... as long 
as you can predermine how all the coordinates map in both systems. 
 This last part is what just about every importing/exporting out 
there tries to get just right... but in the end, its never exact 
because coordinate systems are different, font rendering engines 
don't use the exact same algorythms, etc, etc, etc.

in R3, all text is rich text, but you don't notice that, since it's 
only really taken advantage of in a few styles.

cool.

something that was sorely missing in R2 , and isn't readily available 
in all GUI systems. :-)

maxim that's like if i was asking you to do 3D secenes in XML format 
because hey man i have thet vid xml-opengl rendering black box that 
will do the work for you but hey you don't have any control upon 
the rendering engine

MD doesnt include images or complexe paragraph formating ... that's 
just a toy

no its like saying I must convert any kind of 3D geometry to any 
rendering engine out there.  Same if we want to export them... a 
model from maya has to be converted to another format if you want 
to use renderman.  all of the scene management is independent of 
the 3D atoms being used.

the rich text has all of the format and explicit position info... 
if you want to slide text in order to add an image inline... just 
do so.  ;-)

as I said, we need to know the offsets... if you really want to use 
another layout engine, just wait for extensions to support image! 
and go crazy  :-)

hum but  in general you do your best to select the best 3D file format 
 to go with your custom made 3D engine to get the best rendering 
real time speed and that best quality compromise.

and that's exactly what an imposed Markup dialect forbids to you 
point.

more low level instruction to make y world easyer why not ? ...  
being tied by the neck and forbid from freedom no way !

maxim with an imposed close format and an imposed close black box 
called "doc"  what you gain in a hand you lost it on the other hand 
cause you still have to convert your raw data into the specifiq imposed 
markup language and if that markup language have limitations then 
you have find again new tricks to do what wasn't planned to be done... 
 that's not like choosing your own format and then your own rendering 
line. That's why i said in my example we impose to you the use oof 
XML  sheets to represent your 3D data (which is obviously far to 
be the most performant and the most suited to that use) and you are 
stuck to what the black box is able to do no way for you to directly 
have an impact on the rendering line.

but there is no link between make doc and rich text.

The rich text dialect is a data structure, not a markup language.

It seems insert (and maybe even change, remove) are already implemented 
for parse? At list this is how I read between the lines of Carl's 
blog reply in Either related blog ...

Yeah, though diifferently. I'll write up the changes in the parse 
proposals page.

it also seems Carl interprets 'either differently too ...

Differently every time you ask. I've requested that he respond to 
my comments.

'check seems to be implemented as 'if?

I've seen no indication that CHECK will be called IF, but given that 
my ? proposal will be called EITHER, it would probably be alright.

And it looks like it is the ? | model I put here :)

http://www.rebol.com/r3/docs/concepts/parsing-summary.html#section-3

look at the table - insert/change/remove is there, as well as 'if

hopefully I am not wrong?

'into does not seem to allow other types yet, we don't have multiple 
to/thru and 'use. Hopefully those get added in first iteration of 
parse rewrite ....

multiple to/thru  are near the top of the list... and Carl recognises 
their use... and probably they where the first requests, ever for 
parse.

they were long time dismissed by many, but I am glad the attitude 
changed :-)

yes... how many times I heard the term... it break's parse's "purity" 
 yerk...  it makes me loose money (cause I have to spend more time 
writting complex rules for simple tasks).

:-)

Updated the proposals page with the changed proposals (to the best 
that I can figure out).

Could someone decode how to read 'either parse syntax? I am still 
confused. The word is absolutly wrong, if infix, I can only imagine 
it, if prefix.

[parse "ab"      ["a" either "b" | "c" | "d"]]


How to read it, please? If "a" is being matched, then try to match 
"b", or try to match "c"?

Think of it as ?

My other word favorites are:

then (absolutly best imo)
try
only

did we ask for too much and unleashed a monster in Carl?  ;-)

also
 would work here. a also b | c

I'm thinking that giving too much fun stuff for Carl to do is scary... 
he should go back to extensions...  or maybe not... he might popup 
a full ANSI C parse rule,  in an hour, just to prove its easier than 
before ;-)

a 'WITH b | c