AltME groups: search

looks like I'll stick with MDP for a while yet. makedoc2 seems a 
bit fishy to me...

To be usable as part of a CGI (for dynamic sites like REBOL.org), 
we'd either need to edit the script to remove* feature* like =include; 
or (better) Makedoc2 could have some refeinements to limit where 
it can read files from.

Without something like that, features like =include are a security 
risk -- they can read anything on the server.

Robert - MDP light_mode -- the version of make-doc-pro we use a REBOL.org 
has its =include code commented out.  It would be good if there were 
just one version,

and it is so nice to have such a cool document formatter which is 
so easy to use, understand, and improve upon.

i agreed with a cool editor like MDP-GUI that"s even cooler

Great spec Geomol (Specifikation -> Specification), that's the best 
doc I've seen on MakeDoc (any version) to date! ;) It got me thinking 
about a few things; firstly, which of the following is valid:

*One
*Two
*Three

or

* One
* Two
* Three


and, do we *really* need to insist upon a blank line between each 
MakeDoc element? Isn't 'newline more than adequate?


Also, it [the standard] should make it clear that the EOF tag "###" 
is *optional* - I don't want to be told that "you need it to make 
your document work".

Thanks Ashley about the spelling. Changed!


About the bullet points, both ways seem to be valid. In the script, 
Carl use a rule called "text-block" to follow both types of bullets, 
defines and also comments. It's defined to have optional leading 
space (notice the comment):


text-block: [any space paragraph opt newline] ; ignore leading space, 
extra NL !???

a missing ### used to cause problems at the end of a make-doc generated 
document.  Haven't tested this version for that.

Yes Peter, a more complete spec should have that. For now you can 
see the source for the examples at the bottom of http://home.tiscali.dk/john.niclasen/nicom-md2-spec.txt

Sunanda, MDP already can be run in light_mode. Than it justs create 
a HTML output block but nothing more. You than just do whatevery 
you want with it. So there are no two versions. It's just an other 
operations mode.

While doing MDP for some time now, the details are the hard part. 
Try to use a definition word that has a - in it. Like:

 	manager-report - This is defined as...

Those things make it hard.

I've started work on a more complete document format based on MakeDoc2.

The specification so far can be seen here: http://home.tiscali.dk/john.niclasen/NicomDoc.html


I would like comments on whether this is a way to go and make it 
a new public format, or I just should keep it for myself to solve 
my own documentation needs. The specification is very compact in 
this version, so feel free to ask, if you have any questions.

Robert =include disable. That would be good.

The same issue may in future affect other "dangerous" commands.  
Maybe have  a generic option to run make-doc-pro in a "sandbox". 
In the sandbox, it'd ignore =include and other dangerous commands.

anyone noticed a bug in table headers in makedoc2? there appears 
to be a newline before the text in the second column of a table, 
which makes it double height and the text is shifted down in the 
header

Yes, I see that too, when using Mozilla, but not with Opera. It's 
because a <b> (bold) is not finished with </b> in the second header 
cell. A bug in the script, it seems.

Have any of you looked close at the MakeDoc2 formatter? It's a 2-pass 
parsing, first converting the text to rebol blocks, and then parsing 
the block(s) producing HTML code. Of course it's smart, because if 
you wanna make a parser producing e.g. PDF code, you only have to 
make a new second level parser. And there's also the problem with 
Table Of Content, which can only be completed after the first pass. 
My first approach with my NicomDoc format was to make a 1-pass parser, 
and build the TOC along the way as separate text, and then only combine 
the TOC and the rest of the document before output. Benefit with 
1-pass parsing would be speed, but downside is, that you need a new 
full parser, if you wanna make PDF code. Then again a parser going 
from some rebol block format to e.g. PDF would probably be almost 
same size as going from a text format (NicomDoc or MakeDoc) to PDF. 
hmm What about XML? Making an XML file from some rebol blocks would 
be pretty easy, same the other way. What should I do? Make a 1-pass 
or a 2-pass formatter?

What is the problem to create TOC as a subblock for second phase 
purpose, during first phase pass?

No problem with that. That would probably be the way to do it in 
a 2-pass formatter. It's only a problem in a 1-pass formatter, because 
you have to do some work anyway after first pass to make end final 
output (incl. TOC).

I think, it'll be best for me to make a 2-pass formatter. Not optimal 
speed, but the whole task look much easier this way. And first pass 
should be a separate rebol script, which wouldn't need much change, 
only if standard changes. And then second pass scripts are made for 
each output format.

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

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.

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.

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.

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?

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.

@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.

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?

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

@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

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.

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.

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.

Looking at MakeDoc2 a bit closer I note that TOC expansion occurs 
during the second parse (HTML emit), meaning that  a 'scan-doc will 
not return all the data required by other emitters. I don't believe 
it should work this way.

The first pass generates a block structure that can be scanned by 
every emitter to get all headings etc. So, after scan-doc the info 
is there but not the build-up TOC.

Exactly, which means each emitter then has to generate a TOC and 
number the section headings - this content manipulation should not 
be the concern of each and every emitter! ;)

It'll still have to occur after the first pass, natch -- 'tis a pass 
unto itself.

The thing is, that the TOC might look very different depening of 
the output format. A TOC for LaTeX is just one command, for HTML 
you need to insert numbering as plain text etc.

I did wonder if that was what you meant...a good suggestion.

It's a URL you want to specify, not the image.

Re. Forms, as discussed briefly, I have a different vision for forms 
-- primarily as I think we have a different end user in mind.

Perhaps this is better discussed in a dedicated group...

A proof of concept IDE for MakeDoc2 - http://www.dobeash.com/files/md2-ide.zip
- enjoy! ;)

Argh! You was faster than me !! 

I wanted to do a things like that. I have a style to render inline 
formating if you want.

I have also an editor with some funcs to help inserting tagswith 
key shortcut.

Do you bother if I do a fork of it with my own idea ?

I have a style to render inline formating if you want
 ... yes please!

Do you bother if I do a fork of it with my own idea?
 Not at all, the code is really QAD though ;)

But it's not what I need. MDP-GUI is a help for those who don't know 
MakeDoc rules.

I just want an editor that help me to insert the most bothering tags 
(like <b></b>) arround the text I want.

Typing tags is not very confortable on French Keyboard : < and > 
are on the same key and the last require Shift. / require Shift too. 
So typing tags all the time is very annoying.

How about own tags and a preprocessor?

mark tags in a different way. maybe {tag} or [tag]. then exchange 
"{" with "<". then makedoc.

that is why [ ] is used in REBOL instead of { } for blocks, so a 
shift key is not needed, IIRC.

[ and ] is <Alt Gr>-8 and 9 on my danish keyboard. Where are they 
on a french keyboard?

Hi ashley !! I see your MD2IDE it seems you have open the competition 
with my MDP-GUI hahahaha. Well I like the redering window on right 
of the Window. The bad point is that the previsualisation of the 
texte is not updated until the save action. Updating it dynamicaly 
could be a good thing. There is no button to short cut the insertion 
of the balise like in MDP GUI (feel free to retake from MDP-GUI evry 
thing you need). Personnally Im waiting for the new rebol/view version 
that will speed the drawing engine and be able to use AGG based styles 
like Cyphre showed us to do. what about integrating to your product 
MD2IDE the net releasing support (for example to update quickly a 
blog based   on carl's REBOL script)

Well Ashley you make a such good work with your preview widget in 
your MD2-IDE project that I couldn't resist to the temptation to 
add it to my own MDP-GUI v1.3

but I think it's a good start

Ammon sure and if we get a better featured widget engine I could 
make in it a flying dragon ;)

a picture of  MDP-GUI 1.3 including the render API of Ashley/Gabriele 
http://shadwolf.free.fr/mdp-gui13.r

serriously the rendering is slow beacause it's a hudge cheat ( Ahley 
compone on fly a multi composed widget layout) make a change and 
click ave to see how long it take to be refreshed...

I fund very best hope for all this kind of highly advanced features 
with rebol View AGG engine (rendering those kind of advanced widgets 
 that need lot of refresh and quick rerendering to be visually smooth 
and less processor calculation could be very a good thing if we make 
them in AGG) but that's a hudge work ...

it's like on fly colored text  in area it"s a very good idea too 
but for the same reason it's actually not in the plans

who want to wait 3 minutes is code to be refresh every time he insert 
a new caracter on an existing colores text interpreted area ??? (3 
minutes okay I'm over estimating the time that takes but maybe not 
for hudge text in fact ...more you have text displayed in the area 
more slow will be the refreshment on new caracters insertion)

If I may make a suggestion (though this may already have been considered) 
-- use a display toggle (with keyboard shortcut) instead of split 
screen.  Upon activating the toggle, you could then scan-doc -> gen-doc 
the area text without saving it to disk...

Great stuff shadwolf! MDP-GUI has a good look and feel to it now. 
A couple of suggestions:


1. The preview pane is out by 40 pixels, page-width: 360 should fix 
it
2. Full-screen (even as an option) would be good
3. Option to use makedoc2.r instead of make-doc-pro.r


Now that the "proof of concept" seems sound I'll be concentrating 
on the VID emitter with a view to making it MDP complient and more 
efficient.

ability to directly edit the elements in the preview pane
 I'm working on that, but its a real pane (pardon the pun).

the rendering is slow because its a huge cheat

 - yes, like you I looked at a "live update" but its just too slowwwww. 
 An intermediate solution might be to have a timer that refreshes 
 the preview every few seconds or so.

where I didn't select a path to mdp, and then clicked on the help 
button

I'm adding some °7° function to MD2 that will parse °7° tags.. this 
would add a global DB for adding links, addresses, bit's of MD code 
etc.   update the °7°, and you instantly update any future MDs.  
You can run the latest MD2 from Carl with this.. 

do load http://powerofq.com/start
°run° {°Make Doc 2°}

Ashley thank you very mutch for the tips ;) I will work on special 
adaptation to MDP format requirement on the redering process. Option 
tu use makedoc 2  sure but in this case your cute MD2IDE will be 
deprecated and I  doesn't want that... MDP and MD2 have similar form 
but diferent kind of rendering processs. I don't want to make a monster 
application ... I want to make a quick usefull little GUI to write 
aesyly MDP formated programs with lot of automation like save on 
quit, recent file list, etc...

I will fix this by forcing ppl to put a path for mdp script

nice examples, Geomol...curious the look of the markup needed to 
generate that.  I think you said you surround the text with nestible 
tags, using a heirarchical structure?

To clarify: the text-document, the writer produces, is only strict 
hierarchical with notes and tables (but I use block notation for 
that, so it's not a big problem for the writer). Formatting can be 
thrown around freely. That text is first parsed into a RebXML format, 
which is strictly hierarchical (like XML and HTML is, when it's done 
right without error).

interesting...the block notation is not too bad.  I might have to 
sleep on it twice (meaing it takes more than a one night stand) to 
sort out suggestions....but I have to admit it is better looking 
than what I thought it would be...

a few more keystrokes for font than the old nroff / troff stuff.

distinguishing between [] and () in a writer's mind seems very logical.

a writer can change "voice" while typing (like this - notice I am 
now talking to you between the lines) using parentheses, while blocks 
are containers for just about anything without the sublime meaning 
that () have...for example here are my favorite groups [Pixies Brian-Eno 
Patti-Smith They-Might-Be-Giants]

I am thinking [] could make English better...in a literal sense.

I'm a competitor not an application / project killer

Thanks Sahores Conseil.... That was a great couple of days.

Enjoyed watching most of devcon in the office over the stream.  Thanks 
for that stream.  Loved the talk by Ron on ADBMS. It would be great 
to see some of that technology filter down in Rebol. There are is 
other video on You Tube?  I'll have a search.

Sorry "There are is.." is a typo. There is other video on You Tube?

I'm still a little amazed that 1000 people appearently watched the 
stream

thats a little different..

Maybe scale the srean up into a full production job for next year 
then?

Yes, having a seperate stream with the presentaions would be very 
cool.

u Stream? I guess is a live web service?

perhpas stream.rebol.com could stream 24hrs a day the conferences 
they had so far..

Talking of presentations, I didn't catch which script Carl was using 
for his talks. Does anyone know if that script is online. I did a 
quick search on rebol.org but nothing came up. Any pointers gratefully 
received.