World: r3wp

Robert : For the structure, you can look at my 'Easy-Doc prototype:
http://rebol.dev.fr/view.php?sid=141
It works with 3 sets of modules: readers, parsers and writers. 

'readers have to supply a text string to parsers (ie. MS-Word files 
are scanned for text),

'parsers build a block in intermediate format (there is a makedoc 
parser,)

and 'writers output the result either in file or on screen (VID / 
html / pdf / rtf / swf).

Thanks I take a look. Well MDP is quite old and IMO needs some refactoring 
:-))

I was thinking that another good feature to add for makedoc is a 
javascript popup link

Maybe incorporate tag symbols in the text for the parsing

Did some one found a way to have a FAST Rebol editor.  I did remarked 
that the cursor is slowing to a crall on big texts in MDP-Gui.  It 
is also quite slow with VT-editor or ion-pe, or even with this very 
small editor in alt-me, the one with which I write now.  Tcl, for 
example, does have two tk texts widgets (text and C-text) to properly 
handle text.  Could there be a way to have a fast editor in Rebol, 
something that could handle a text of 100-200 pages in a manner that 
is as fluid as something like notepad.  I am a newbee and find MDP-Gui 
to be a nice course on how to play with text rendering.  Although 
I would rather have only one window, and alternate from the editing 
window to its rendered view.  Full window is nicer to write text. 
 Side by side is nicer to compare marked-up text to its rendering, 
but after a while, we know the rendering and simply want the fuss 
a a nicely rendered text.  I am fidling with this idea, but do stumble 
on the editor part.  I dont even know who is the culprit, area or 
the ctx-edit.  If someone has a simple solution to this, he should 
post it.

Normand thank you for your concern about MDP-GUI. AS MDP-GUI main 
author I can say that the one vindow rendering is one of my futur 
goals. By default Area are absolutly unable to handle ritch text 
..  Carl Sassenrath plans to add a new VID widget to do so called 
TDM... (But The double formating maybe very slow). MDP redering format 
pull us to have en extensive use of VID widgets capabilities I'm 
not sure even with TMD we could reach the same level of beauty. I'm 
making some research too on my side to  found a pretty way to transform 
redered widget to editable ones keeping there settings... But so 
far I wasn't able to produce a relevent soution in this issue :)

One pist could be to systimatically clone itch widget having them 
in two ways the first one would be a redered form based on face the 
other one would be based on field and will have stricly the same 
setting than it twin  If the rendered widget recive a mouse down 
even then we substituate the redered widget base on face by it's 
clone base on field  once this last receive a key  enter  event type 
we affect the clone content to the redered widget .... But with this 
system pref will be verry slow !!! and memory consumsion will be 
twice important ...

My actual effort in dev leads me to rebGUI project so MDP-GUI is 
in pause until rebGUI reatch stability then I would make a brand 
new version of MDP-GUI including the RebGUI look&feel. Once all this 
work will be done I could switch back to "One render/input window" 
problem :)

But as you say it normand it's not an easy topic so being able to 
solve it will be in my opinion a community effort because we need 
a little more than TDM  (to render tables for example... )

Last thing the pointer is slow on hudge text because of this F***King 
mad system base on caret  to handle the cursor position you store 
the current text that belongs after the cursor Writing and rewriting 
every time into this caret buffer the most part of the document is 
super slow  !!!

that explain why on hudge text the cursor of an area widget is slow 
;)

If I understand you well, the only way that we will be able to settle 
the two problems of :

1- caret repositioning in a big text and 2- rendering text in the 
same window that we edit

will be to settle it by inverting the problem : edit text in a console 
or an editor, and have the console or editor to parse the text and 
transform it according to the commands it find in it.  I did search 
for that.  The closest library to such goal I found is either scintilla 
for an editor or tkcon, the adaptable tcl console.  But all this 
suppose that we dispose of Rebol source code to put the language 
parser in it, right (like ion.pe)?  So we would have to rely on R# 
(open source) instead of Rebol?  Either way, it does seem that handling 
the problem well is pushing us out of Rebol; not a charming proposition. 
 I am just expressing my frustration of not being able to solve a 
problem that is not existing in other languages.  As a priority, 
I do think that the repositioning of the caret is the show stopper. 
   I could live with NOT rendering in the SAME window as the editing 
window; I consider it a form of cosmetics.  But I can hardly ask 
people to start edit documents in a lame editor that takes seconds 
to go from page 120 to 130.   It would be nice if RT could find a 
solution to that, as it would ease the way to specialised IDE's, 
Ide for Rebol and the many specialised dialects.  By the way, did 
Ammon Johnson finished to wrote his REBOL-based IDE, called RIDE?

Carl offered at least the source code for the Rebol console in his 
Blog about Rebol/Coop http://www.rebol.net/article/0146.html.


As I routinely use Scite based on Scintilla, I think, that this should 
be sufficient regarding the perfomance.

hum MDP rendering is far away more complex than scite capabilities 
... So we have no other choice than invent a new way to deal with 
this

If you want a renderer and text box on the same page, just throw 
a wrapper around http://www.ross-gill.com/make-doc/and have the 
results show in an i-frame. piece of cake

allen Iframe ? and why not java ... are you joking having rendering 
and writing in two panes is yet possible with REBOL/View (see MDP-GUI) 
What I seek for is a merge of both systems Like MS Word But even 
sharper and made Fully in REbol/view code no external call to other 
idions technology :)

scintilla is better than basic area but is still from what we need 
in MDP

example tables  rendering is unable to be done with it but you get 
colored text, by caractère formating wich are yet an improvement 
from actuall area

based on iframe + java technology you have the ritch text editor 
projects is what I want to be able to do with VID. But I have no 
concrete idea on the method to apply to get it

http://www.kevinroth.com/rte/demo.htm

what's the point of doing the display in rebol if you are doing html 
as output format? May as well render it in the browser.  rebol/plugin 
in the browser could do it

I think he want to render MD as VID or Draw (as MDviewer does) but 
with an inline editable capabilities.

Exactly dideC but MDP-GUI yet renderise the documentation in VID 
like mdviewer. Why to see it in rebol/vid simply because it better 
IMHO to have a render preview and the MDP raw format in same window 
...

HTML rendering is for the publication of the documentation not for 
the preview of a building stage doc ...

Now next evolution of the rendering system mut be a fusion betwin 
the MDP raw format and the MDP to VID renderer.  In order to have 
on one panel that display the doc. Ths will lead me to write a multi 
file handler as we have only one panel for each open document. Save 
wil be made by default in .txt files and you still get the possibility 
to render HTML when you judge the document is publicable

Someone asked me about NicomDoc recently. I just added font support 
and escape mode (to turn on and off using backslash as escape character), 
changed some definitions and fixed a bug or two. I'll add options 
and make it version 1.0 targeted at HTML output. Should happen within 
the next days, where I'll release it.

I've updated the NicomDoc example document. It can be seen here: 
http://home.tiscali.dk/john.niclasen/nicomdoc/

I came to version 1.0 of NicomDoc. See Announces! Next I will specify 
the RebXML tags used by NicomDoc, which will be needed, when making 
output engines for other formats than HTML, and to make input engines.

I would like to create an IOS Wiki application based on MDP syntax. 
So it should be a Wiki I can use as IOS user and browse / edit with 
some kind of editor. Here are some thoughts (unstructured). I'm looking 
forward for you comments.

1.) How to handle CamelCase links and content?
	- One approach is to create a TXT file for each CamelCase word.
	- Than new files need to be autoadded to the fileset or

 - The editor recognizes CamelCase words and creates new files, this 
 implies the the internal
	  editor is used.


2) MDP needs to be extended to translate CamelCase words into links 
that MDViewer can handle


3) Filesync clashing needs to be integrated into IOS with DIFF/MERGE 
option based on the synced TXT files

1a) i use "%" as marker, not camel-case. and store everything in 
file. currently i use this to add relative links to make-doc-pages

1b) a reblet could check all links, and suggest to create missing 
files.

2) i use the "%"-translator as a preprocessor, so i have not to patch 
the make-doc*.

3) Have a seperate work-folder for each user. so auto-downloads would 
not overwrite it. and then you can use your prefered merger if there 
is a clash. its all files then.

3) the Wiki should be shared, as a growing knowledge-base

2) This could be implemented without a big problem. Either for CamelCase 
or % marked words. Whereas I better like the CamelCase idea.

3) one public folder and one for work. if files clashes, both have 
their original working version and can merge.

you edit in work-folder and when done publish to the public folder. 
with some reblet which shows you which files you changed, and maybe 
checks links.

how about a simple general purpose version tracking system for makedoc2/mdp? 
if done right, it could be used alone or with IOS. Carl talked a 
while back about some simple diff commands for future rebol versions...

I'm getting ready to make some changes to the make-doc spec for my 
own use to include some extra formatting for bible verses.  I want 
to be able to put in some specs that allow for wrapping of verses 
and a horizontally wrapped contents spec to go to a specific verse 
in the Book title.  I haven't looked at the code yet so I thought 
I would jump here and post this and hope for some quick pointers 
on how I should approach the code before I begin.  Specifically what 
parts of the code will need to be altered or what I should look out 
for and maybe what kinds html tags should I implement for the wrapping 
of verses etc..

Paul, you might try posting a specific example of what you want the 
output to look like.

you can actually put some html tags in the text para depending if 
that achieves what you want.

(without modifying make-doc, I mean)

Paul, MDP has a horizontal TOC option. Not quite how you want it, 
but you can take a look at how it's done.

Paul, One thing to keep in mind is that you should want to leverage 
html stylesheets. 

In your make-doc version add the reference to the class then let 
a .css determine most of the presentation parameters.

For example, I wanted to be able to add a question and have it presented 
with a heading very similar to a note box

but to have a different label i.e. "Question" and a distinct look.
This change was required to parse it 

 ["=q" | "q:" | "question:"] text-line (emit-text 'question) |

from the input stream. This emitted the html 


 question [emit [{<p><div class="question"> Question: &nbsp;&nbsp; 
  } doc/2 {</div>}]]


Change the make-doc script you are using to emit a reference to your 
stylesheet instead of inlining it.

I put this in my css to present a question in box that stands out 
(for me)
  div.question {
     	padding: 10px;
        background-color: linen;
      	font-size: 14px;       
     	font-family: Helvetica;
        border: 6px groove gold;
		width: 90%;
  }  

The reason for .css is that now you can change the stylesheet and 
don't have to change the html or 

re-generate it. If you want your question box to tan instead of linen 
then you just change your .css

If you have something you feel strongly about you can create a soapbox 
style.
For more on this see http://www.csszengarden.com/

p.s. when you change make-doc, clearly identify the lines that you 
change with comments so that when 

you get a new version you can retrofit it and get the benefit of 
the upgrades.

Thanks guys I will give it a shot and let you know how it goes.

I'm close to have ended the MDP-Browser software. Lots of improvements 
have been done and makes it a tool a step forward MDP-GUI.

what is MDP-Browser ? MDP-Browser is a software designed to work 
with IOS server  in a wiki like way. MDP-browser is a merge betwin 
MD-Viewer and  MDP-GUI some kind of nutural son of those two programs. 
It's similar to his parents but entends truelly the capabilities 
of both program.  First of all VID rendering have been improved (bullet 
points  are drawn using effect/Draw and not any more ascii chars), 
Viewed text resizing exist

it handle the window resize too, Toc area is inserted into the same 
window and the entry clicking now scroll allways on the top the viewing 
area, MDP-Browser can produce HTML docs by just clicking one button 
the HTML  is stored localy and can be published back to the IOS server 
using the IOS REBOL/link client plublishing system. Editing of a 
document is possible existing on the IOS server or new we can store 
locally or publish it back (if the fileset yet exist on the IOS server).

you have builting doc history that allows you to browse several files 
and get back to them...

those are the main functionnalities but there are many more things 
in it ;)

Paul, 


For what you have described, you may want to use navigation like 
that provided 

by a java script outline tree. One example is http://www.treemenu.net/
  


My plan is to soon make a make-doc revision that takes as input the 
NoteREB data from the
script by Alain Goye.   http://alain.goye.free.fr/rebol/NoteReb.r

Then generate an html site using the same tree structure as the NoteREB 
source file. 

Each page from the NoteREB data file is to be make-doc'ed into a 
separate HTML page.


NoteREB uses a very simple REBOL block structure to hold the content 
and sub-blocks.


If you want to change a page, change the source page, save the file, 
and click the new

reGEN button.  Alain's tree makes the management of the source much 
easier than methods
I had been using before.


I have used this approach for taking easy vid format and making an 
easy vid presentation 

format.  That means that it makes VID faces for each page and allows 
the execution of sample

code by clicking on it. Seems to work well and I plan to put it on 
the script library 
after View 1.3 is released and I can verify it works OK there.