World: r4wp

Hmm, I think you are in fact mixing up implementation with syntax. 
Are you saying that MakeDoc markup is not something that can/should 
be able to be processed by non Rebol tools?

Whew!  Not being clear.  The DOM is the result of taking a simple 
Hypertext engine and trying to turn it into a application architecture. 
 Everyone adopted it because it was widespread, not because it was 
good at appications.

Uhhh...

MDP is a dialect of Rebol.  It takes advantage of what Rebol does 
well.  Is Markdown a dialect of Rebol.  Is the syntax optimized to 
play well with rebol?  That is my question.  If not then we need 
somethign that plays well with REBOL.  We can alway output MarkDown 
if somebody really wants it.

Scot, MDP is string parsed and markdown is string parsed as well. 
MDP actually works by first converting line by line into another 
dialect, which then is parsed to HTML.

MDP is string parsed
 - and this part is actually a big mess.

I've spent a lot of time with MDP, written a whole distributed application 
with pages based upon the principles of MDP.  The biggest mess in 
MDP is the need to make HTML pages, which is a fossil and pretty 
awful, but widespread.  People need HTML so we output that.  People 
may want PDF, or RTF or Postscript or MarkDown, or whatever.  Those 
parts will always be a mess because the formats of all those outputs 
are a mess.

I've also spent quite a lot of time with MDP as well building now 
around 2 megabytes of manuals with it, and I spent some time adding 
new features to it. I wanted to add a glossary feature, but it's 
quite strained with what we can do now. The HTML part is not so bad. 
The line parser is much worse, both because we are running out of 
space for sensible inline rules (which all are one-char and markdown 
doesn't have this limitation), and the code itself is not very well 
organized.

I would gladly toss out the MDP parser for a clean markdown parser.

wouldn't Carl's original makedoc.r be convertible with not too much 
effort?

I think it has fewer inline rules.

Gabriele also did a variation for Qtask. Not sure about compatibility, 
but it would be more modern, and likely a very clean implementation.

Gabriele's MD3 is fairly awesome, imo. Very easy to build MakeDoc 
'dialects'.

Has MDP ever been really associated with RT? I always thought it 
ways Robert's creation. Whereas MakeDoc and MakeDoc2 where Carl's 
stuff.

No, I don't believe it was.

It is a superset though, iirc -- any MD(2) document can be processed 
by MDP.

we should probably try to make it clear for newcomers when we mean 
MakeDoc(2) vs Markdown, which some people might think MD refers to

Scot, on generation: Gabriele's FSM emitters (particularly for HTML) 
are the most elegant solution to this I've seen. I use it often.

Adrian, I'm not certain, but I believe the settled extension (and 
I suppose shorthand) for MakeDoc is .rmd (Rebol MakeDoc).

I just meant in here - someone dropping in/by might get confused 
when there are references to MD

Could you all please test the https://github.com/BrianHawley/r3-bh/tree/length-embedded-script
fix? Carl wants more testers before he accepts the https://github.com/rebol/r3/pull/40
pull.

Could you maybe write up some testcases?

The only externally visible change is that sys/load-ext-module and 
sys/load-module return 3 values instead of 2. If you don't have any 
code that calls those functions directly, then all working code won't 
be affected. The only code outside of sys-load.r that could hypothetically 
call those functions would have been written by Ladislav for include, 
or Saphiron for their encapper, but even then it's unlikely. Andreas, 
you could grep Saphiron's sources to tell me if those functions are 
referenced outside of sys-load.r.

The only behavioral change is that length-specified embedding works. 
It was documented before, but didn't work because the code above 
sys/load-header didn't support it. With this it does.

Where is "length-specified embedding" documented?

I fear that with the pull request as-is, even basic script execution 
is broken:
$ cat foo.r 
REBOL [] print 42
$ ./r3 foo.r 

** Script error: select does not allow integer! for its series argument
** Where: make either either -apply-
** Near: make system/standard/script [
    title: select first code '...

>>

I don't even know anymore. I'll write some example code. If your 
script dowsn't have length: some-integer in its header, it won't 
be affected.

Alright, let me check that.

That code in in sys/do*.

Wait, it's not, do* uses select hdr 'title. That's in the fake do 
in sys/start.

Let's not pollute the group. Continuing privately.

OK, it works now.

MDP is a dialect of Rebol.

 - actually, it is a dialect of Rebol exactly like C, i.e., not at 
 all

To clarify, a dialect needs to be REBOL loadable data, not just a 
string that is parsed.

Pekr, R2's console was GUI on Windows, not a real console app. Carl 
had wanted to make an R3 console like R2's but better, in the R3 
GUI. We just never got around to it.

Some of the rest of us (me particularly) had missed the Linux/OSX-style 
real console for R2, and saw the advantage of having that as an option 
in R3. We never really got that because R3 opened another window 
instead of operating in the console it was called from, which turned 
out to be the worst of both worlds.

Carl's blog was about the inline text-mode problem, trying to solve 
the open-a-window bug. That wasn't about the planned GUI, it was 
about fixing the existing console.

brian, iirc, it was about inability to have view exe being used as 
real fonsole. Carl did not find a way of how to do it ...

If you are talking about the existing R3 console, the problem was 
that he couldn't make a real console-mode R3 program without losing 
functionality that he only knew how to support in GUI-mode programs, 
and he couldn't make a GUI-mode app use the Windows console without 
allocating its own console window, which lost all of the advantages. 
It's not to say that this can't be done, just that noone who had 
the interest and ability to do this had made the effort, because 
it was low-priority for the contributors at the time. With more contributors 
now, perhaps this will get fixed.

If R3 is able to use the real Windows console instead of its own 
console window, you could solve the color scheme issue by using an 
alternate console - there are many - or changing your settings. It's 
up to you. However, if it allocates its own console window then you 
can't use any of the alternate console managers.

Hmm, maybe the author of ConEmu should be approached about this - 
maybe he'd be interested in order to get a scripting language included.

http://code.google.com/p/conemu-maximus5/

Stuff like that is what we had in mind as an advantage of supporting 
the regular Windows console, Adrian. That and remote console or powershell 
use.

You can fix the "own console popping up" for Win32 R3 right away, 
if you have MSVC installed: 
$ editbin /subsystem:console r3.exe

Then r3.exe will use the "real" Windows console, when launched from 
one.

That's the console-mode app thing. This supposedly caused problems, 
which Carl asked about in the blog.

That's responsible for r3.exe having to pop up it's own console and 
not being able to reuse the parent console, if present.

Right. But supposedly changing the app to console-mode like that 
caused other problems, which I don't remember because I don't have 
a link to the blog in question.

Also, is it possible to just compile it that way in the first place? 
And is it possible for such an app to bring up a GUI, say so that 
it can run console scripts and GUI scripts?

The other problems need to be ironed out :)

Such an app can bring up a GUI, yes.


However, it will always pop up a console window (which can be closed 
immediately, but this will result in the "console flashing" effect 
some dislike).