World: r3wp

That seems the way to go, unless you want to make a compiler compiler.

Yet Anoter Compiler Compiler? :-) No way! ;-)

Another**

Just migrate some more hair from the top of your head to your chin. 
You'll be fine ! :-)

Geomol, MDP takes the same approach. 2-pass parser.

More precise: 2-pass script. First parse, second generate.

I've updated the NicomDoc specification: http://home.tiscali.dk/john.niclasen/NicomDoc.html

And I've started implementation of the first pass of the formatter.

Why again a new one?

Carl made MakeDoc and started a project some months ago to define 
MakeDoc2, but it seems, the group fail to make progress, so Carl 
wrote something about it lately and published some scripts. As I 
see it, MakeDoc has some bad ideas around commands like \note /note 
\table /table and so. Those things should be strictly based on the 
hierarchical datamodel, else users of the format WILL make errors, 
as we see it with HTML, XML and the like. And MakeDoc2 also miss 
bold, italic and the like, which is done as HTML tags. I need to 
make a lot of specifikation and documentation for my projects, so 
I desided to make my own format, that suit my needs. I don't know 
yet, what I should do with it yet, but I'm going to do it. :-)

I hope, it'll be part of a general format, everybody will use, some 
day - maybe merge with MakeDoc2!? It's not my decision.

(ops! I made some bad sentence construction there. Sorry about that. 
I hope, you understand me.)

You know make-doc-pro?

make-doc2 is a current interrim which has his improved starting point, 
so we don't have to start with make-doc 1 generator

as I said earlier, there are thousands of products which the core 
of make-doc from RT will generate.  It is pretty easy code to extend, 
once you get the hang of it.  Make-doc2 gives us a much better springboard 
to do things right, with a better user experience out of the box.

Maybe I wasn't that clear. MDP uses the same approach as makedoc2. 
Parser and output-generator are seperated. I really don't see any 
advantage in a next fork. IMO it makes more sense to change what 
we have. Feel free to do so with MDP and submit your changes back 
to me. I will integrate them.

It's not impossible to write a Make-Doc(-Pro) parser that is compatible 
with Make-Doc(-Pro) outputters too, but then you lose the ability 
to interchange documents.

It is still my greatest request though, that =anyword and \anyword 
/anyword be a part of the make-doc standard.  Thereby building MD 
dialects based on usage context.

Chris, I agree. Maybe not the most elegant way but it works quite 
good and we have a lot of docs now. So why change it.

I was reacting to Geomol, just trying to clarify, not to your statement, 
Robert.  From RT perspective, Carl said he doesn't want to rewrite 
the thousands of documents already written.  I think for someone 
to get RT buy-in for new versions that RT would like, that is a major 
water test.

I think, for the way Geomol is thinking, that his best approach would 
be to enforce his heirarchical structure on the writer, he might 
need to make his rigor as a pre-make-doc dialect that would feed 
to make-doc dialect.  Not hard to do, or he can bypass altogether. 
 Lots of room for experimentation, since the source is there.  Tremendous 
advances can be made by good experiments.

for =anyword, \anyword /anyword...this type of work is made easier 
by the current release, so it is clearer now how to shoe-horn it 
in.

I think unless you have one already set up (eg. =url, \table), then 
=anyword would become [anyword "Content"] and \anyword would be [anyword-in 
"Content"]

Geomol might find an absolutely huge market for his product, as he 
designs something new the way he sees fit.  That is not something 
we can predict for him.  Markets are fickle.

that seems very clever, Chris.

I had an old version of that idea in the REBOL2 checklist...but I 
haven't brought those forward to REBOL3...been very busy coding...

(your idea, Chris, just not articulated as well as now, is what I 
mean)

Yes, I know make-doc-pro, but I haven't looked at it in depth. I'll 
do that. I've also started to write a comparison of MakeDoc2 and 
my new NicomDoc format - what thoughts, that made me start work on 
an expansion (as I see it) of MakeDoc2.


About other formats already there, I plan to make conversion scripts, 
so you can go from one format to the other. Of course I hope, we 
can all agree on one final format, that'll suit us all.

Robert, MDP is very close to what I'm looking for. Only major problem 
(as I see it after a quick view) is, that MDP uses \<tag> /<tag> 
tags like MakeDoc2 do too. I'll explain in my NicomDoc vs. MakeDoc2 
comparison, why this is a big problem. I'll post here, when my comparison 
is done.

Here are my thought, that lead me from MakeDoc2 to define NicomDoc: 
http://home.tiscali.dk/john.niclasen/NicomDoc-vs-MakeDoc2.html

NicomDoc is not final yet, and I'm only at the state of implementing 
the first pass of the formatter.

Looks good so far. One thing that MDP has that I really like is:

This is *bold* text.

Here is ~italic~ text.

And some _underlined_ text.


I find that these don't "break the flow" as much as tags do, and 
they retain meaning if emailed, etc. A couple more comments:

1) a <title> option for =table would be good
2) a right option for =image

3) Given the nature of Character Level State Changes, is the "/" 
character needed? I think "This is [b]bold[b] text" is fine, or, 
"Here is some [c red]RED[c] text".

If anyone is missing a feature in MDP or has any ideas please let 
me know. I'm open to enhance, change, you-name-it to always make 
it better.

Problem with *bold* is, that it collide with bullet points. How should 
this be understood:

Examples of styles:

*bold*

~italic~


The *bold* would probably be shown as a bullet point. If the parser 
could somehow be fixed to show it as bold, what about this then:

Some math problems:

*1 + 2 = ?
*1 * 2 = ?

Those should be bullet points and not bold. See the problem?

Yes, but MDP handles this :-))

Ok. :-) I'll take a closer look later today.

@Ashley

1) a <title> option for =table. Yes, I considered this. HTML has 
a caption option for tables and optional align (top|bottom). If align 
isn't there, it's up to the browser to deside. I found it a bit confusing, 
and by putting the title of the table yourself at the place, you 
want, you get the result as expected.

2) a right option for =image. Yes, good idea. I've also considered 
the situation, where text should go around images. But I haven't 
found a good way to specify that yet.

3) Is "/" needed in state off tags? Yes, I think so, because it's 
easier to understand, if you have e.g. several bolds after each other. 
Example:

This is some [b]text[/b], where there are [b]several examples [/b]of[b] 
bold[/b] words.
is easier to understand than:

This is some [b]text[b], where there are [b]several examples [b]of[b] 
bold[b] words.

Also if you make a style, that is bold, then you wan't to use [/b] 
to undo bold. Would be confusing, if you used [b] for that too.

wan't = want !!! grrr, irritating error to make. ;-) Well, I'm partly 
from Faroe Islands, so bear with me.

@Robert

I've looked at how MDP handle bold, italic and so, and it almost 
work as expected. I can't figure out, how to make text both bold 
and italic. Also my math examples from above is not giving me the 
expected result.

*1 + 2 = ?
is shown as a bullet point, as I expect, but the '=' is removed.

*1 * 2 = ?

is NOT shown as a bullet point, and I expected that. It's not bold 
either. The result is:
*1 * 2 ?
again without '='.

I like *bold*, ~italic~, _underline_ and -strike- notation too, but 
I'm afraid, it will give problems for some users. What if you want 
to have a part of a word in bold? How will you write a mathematical 
expression with - and *? You could of course use the escape character 
(\) for that, but then you'll have to do that every time, you use 
- and *. What shall the rules be with bullet points and *bold*? No, 
I think, we need something else in the document format, and then 
let users have the option to use *bold*, ~italic~ and so notation 
in a word processor, which can be based on the new document format 
anyway.

About 2) left and right options for =image. Now that I've defined 
the paragraph level state changes =center, =left and =right, it isn't 
necessary to have left and right options for =image. To e.g. have 
right alignment for only the image, you can write:

=right
=image <file!>
=left

Is that good enough?

Logical extension of the "change of state" rules, works for me. ;)

I'm a bit in two minds about alternative ways of doing things. Maybe 
it IS a good idea to be able to also put left and right on =image? 
Is it general a good thing to be able to do the same thing in more 
than one way in a standard like this, or is it just more confusing 
then?

as user i would think about the image, how can i move it. using the 
paragraph to move the image is more tricky. also: can a text be at 
the left side of an image and then centered in that space?

mixing: At the moment MDP doesn't support bold AND italic.

= char: = is used to start a directive, so the simple character should 
work. Looks like a bug :-))

markup style: Try it, * and - can be used standalone and inside words 
without sideeffect. No bold etc. is turned on ;-)) I'm sure I handle 
99% of all cases as the user expects.

bold and bullets are handled correctly in mixed cases as well.

image postion: To much to type IMO.

@Volker

Text around an image can't be done yet, but I'm thinking of a good 
way to support that. In HTML it will be done with a table, but how 
should it be expressed in a document format?

About *bold*, ~italic~, -strike- and _underline_, maybe it would 
be a good idea to introduce a new paragraph level state change called 
=magic (I got the idea from the vim editor). If the writer type:

=magic


then the short form of bold, italic and so can be used. If the writer 
type:

=/magic


we're back to the default character level state changes: [b], [i], 
[s] and [u]. Isn't that a good idea? :-)

I've updated my NicomDoc specifikation: http://home.tiscali.dk/john.niclasen/NicomDoc.html

(NicomDoc is a working title, and I just specify this format, because 
I need to make a lot of specifikation and documentation myself in 
the future, and I don't think, MakeDoc suits my needs. I've also 
looked at make-doc-pro, and it's close to what I need. I hope, we 
can specify one open format, that will suit us all.)

I've also updated my comparison of NicomDoc vs. MakeDoc2: http://home.tiscali.dk/john.niclasen/NicomDoc-vs-MakeDoc2.html