World: r3wp

how can i change that ?

I foiund oki it's available now

good

Sweet!  There it is. ;~>

so ppl now to  dl MDP-GUI 1.4.1 all you need is to append a rebol/view 
console and copy/paste  do http://www.rebol.org/library/public/repack.r

then find in the list MDP-GUI-1-4-1.r all the files in the package

need to be downloaded ;)

Download/install works like a charm.  Nice job on mdp-gui.

thank you brock it cost me a lot to put it online to rebol.org ;)

that to ashley and all the beta tester contributors idea teasers 
;) that allow me since november to heavyly enhance and make progress 
this app ;)

next step to MDP -GUI is to be made using RebGUI and encaped (wrapped) 
 by GREBOX  and a cute little installer for non rebol.org download 
;)

don't know if I could get enaought patience to make an input/rendering 
same window intaface once MDP-GUI interface will be based on rebgui 
;)

thank  to ashley and all the beta testers, contributors, idea teasers 
;) that allow me since november  2004  to heavyly enhance and make 
progress tMDP-GUI ;)

Shame on me, nice job to all working on MD, MDP, GUI, and Ashley's 
MD-Viewer and RebGui.

MDP-GUI Is one person coded but community inspired I love this kind 
of work  ;)

I'm thinking about refining how emiters for MDP can be written. How 
about this:
- The parser part will stay as is.

- There will be a generic scan-doc routine that can handle: string!, 
file!, url! and block!
  The block can be a mix of string!, file!, url!

- Than there will be one generator loop that loops over the output 
from the parser (the intermediate format)

   This loop has a gib SWITCH statement for all intermediate format 
   words generated by the parser

- The particular generator will be provided in a context to the GENERATOR 
function and than only needs to
   contain the function stubs.

What do you think?

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.