World: r3wp

As I see it, I don't think you can apply the same rigour of a structured 
format to that of a free-form text format -- there simply has to 
be some level of user forgiveness, otherwise we need to create an 
even higher level format...

(though perhaps I see make-doc as higher level than it is/was intended)

It is entirely possible to parse blocks into text markup, when you 
want to allow code to automatically generate its own document (that 
is a hierarchical source, source code)

Geomol...your Example in make-doc2, now that you clarified:

\note A note

\group

\table

some text

/table

more text

/group

/note

###

Yes, it's possible! :-) It might also be possible without the group:

\note A note

\table

some text

/table

more text

/note

###


But my point is, that making the standard this way won't prevent 
the writer to type:

\note A note

\group

\table

some text

/note

more text

/group

/table

###


making an upredictable output. And that's the problem. It's not an 
optimal standard in my view.

A way to go may be to make a deep analyse of, what a document is 
- what it consist of. There are basic elements like letters, dividers 
(<br/>), ... Then there are bigger elements (containers) like notes, 
tables, ... And we can talk about change of state like bold-on, bold-off, 
italic-on, italic-off, font change, etc. The containers should be 
strictly hierarchical. The basic elements and the containers will 
be represented in a sequence. The inside of a container is maybe 
also a sequence. Decisions should be made, if change of state can 
happen anywhere, or if going to one state and back is a container 
too. (I'm thinking loud here, you may notice.)

Anyway I hope, you can use some of this input.

I don't see a difference between [ [] [[]] ] type nesting and what 
is currently used...I see that what you call "containers" are what 
the /  \  tags are doing.  Are you saying you prefer the scanner 
to die if the input is "illegal" than trying to proceed with it anyway?

what is there now already parses the "sketchy" usage in a reasonable 
way.

your examples do work pretty good on the new makedoc...just tried 
them in Developer IOS.

impressive.

MDP-GUI to be the interface for writing datas to Carl's blog script. 
does the idea sound usefull for you ?

like adding a publish or blog button to publish it directly to the 
web distant blog

I tried an earlier version of MDP-GUI but did not keep up with it. 
 I would like to try it to understand better its functionality.  
I think you have some good ideas there.

I use IOS to keep version control of my website...so I usually have 
things integrated with that...but the GUI could make it easier...does 
it run makedoc2.r as well?

yes I remember it but it was do to your low version that doesn't 
include teh set-face/clearface etc-face capability ...

oh yes, thanks, now I remember.

I'm trying to do somthing that allows you with a bunch of clicks 
to and some little tipping to make your full doc verry quickly with 
a lot of usefull functionnality like in true texte editors (I dont 
support yet direct texte rendering or color syntaxe) but there is 
some trully good advantages

on makedoc2.r   I can use * ** and *** bullets without trouble, but 
I don't yet understand the 3 levels of enum  should it be #>> or 
>>#  so far neither seem to work.

in the make-spec, there were things like ! and * for numbering ...

Did that get lost somewhere ..?

in front of vi of windows notepad for example it's oriented  Make 
doc Pro (Robert Version) and the look and feel is not has nice that 
if I could include in it the whole widget AGG based set of Cyphre

(I was just perusing the source...the parse of enum2 and enum3 show 
">" and ">>"

but I think is usefull you can earn time using it

yes, a make-doc friendly editor, if done right could enhance doc 
writing even further than makedoc2.r takes it.

being "agile" with lines for such an editor makes sense to me.

agile ?

like cut copy paste ?

being able to rearange lines (more fluid than cut and paste.

ha displace them oki like in recent text editors yes why not but 
I don't have the most little idea of how to concretise this ...

this functionnality could be reused into a rebol RAD (Rapid Application 
Developpement) tool for REBOL too

yes...I have some weak prototypes built, but hope to polish them 
this winter.

like shrink/grow text function object

you get e + ma_func : func [][

I am glad Carl got this 2.5 out...so now no excuses to finish some 
cool tools.

or a - ma_func: func [][
     print "hello"
    print " WORLD"
]

don't understand...sounds like Eubonics.

well i thinkif you exit movable text i will include it a soon as 
possible to MDP GUI that was part of the defaukt fucntionnality I 
allways wanted in it  but has I don't get the knowledge to handle 
the task i send it to futur time

the + or  - is a icon outside the text that ollaw you to minimize 
maximize the function text content (or object )

you open a script with this kind of view you see only the name of 
the functions at screen not there content

for REBOL code, a block-sensitive editor is needed.

when you need to read a content you develope it clickin on the + 
image in the side of the fucntion name

aha...you want to expand the source of the function if they want 
to look?

yes like crimsom editor or emacs that warns you what [ correspond 
to what ]

yep

did you work on RADIS? (trying to remember from my brain.

a good editor i think is the SCITE made for GUI4CLI  it includes 
all this kind functionnality

that not the applicable to MDP-GUI but for rebol rad tool it could 
be very nice

no I present it on devcon RADIS is still pending we get no news until 
devcon on the topic from the autors

but I think this  kind of evolved text earea with syntaxe colorization, 
expend code, line number, text moving could be a trully amazing experience