World: r3wp

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

LOL! I keep typing "specifikation", it's of course "specification".

specifikation
 is danish

paragraph level: Hmm... I don't like it much. Not simple-user compatible. 
Any why provide two ways of saying one thing? I know Rebol has it 
too but this doesn't make things simple.

Yes, that's a concern. hm

It's difficult to judge finally, before I have a working formatter. 
Some things look good in theory, but fail in practical use. One thing 
is for sure, writers should be able to write anything, any combination 
of characters, and get the wanted output in an easy way.

Take LaTeX than.

make-doc and make-doc-pro is for simple to medium complex documents. 
Not more. I don't think MDP is a replacement for a word-processor, 
DTP program or something near like LaTeX.

Good points!

I have to agree... I use MDP for three reasons: It's speedy, it's 
fast and it's not slow. :-)

These are two :-))

:-))

...but maybe he meant speedy in how you can prototype your docs and 
not slow as not slowly generating result :-)

Yes, tools like MakeDoc are about focusing on content, not style. 
It's great if we have a *way* to do more complex things (extension, 
manual tag insertion, etc.), but they shouldn't be a priority.