AltME groups: search

Of course, I prefer REBOL data, with makedoc being my preferred markup 
format. I don't know if Carl's WIP wiki is worth asking about, or 
another wiki engine or site would not lock us in too much. Some of 
us did some work on a wikimedia interface for R3 docs, which didn't 
get far. And I have a wikidot site we can play with if people want.

http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/sys/include/atheos/atomic.h?view=markup

well, to me it makes sense not to reinvent the world and just use 
an existing markup like asciidoc which is intended for documents

No one is going to convince the world to learn another markup language 
like mdp2

That's a very good Brian's comment: "REBOL's rejection of the multi-markup 
madness is a very good thing." (Here: http://hostilefork.com/2008/09/08/is-rebol-actually-a-revolution/
)

Henrik, my initial idea was that it should be possible to make such 
a text/label facet where the text and markup are stored in array/blocks. 
The markup could just be a referral to a markup defined elsewhere. 
Not that I am afraid of a little work but right now I think I can 
manage what I want using just a new textcolor ;)


I named my Text+ field piep and calculated size-text piep to be 0x15. 
Doesn't look correct. Also "word' url" should be "word 'url" in render-rich-text 
/local declaration?

Chris, I am stil figuring this out. I want bold/italic/(underline)/(em) 
paragrapphs separated with a blank line (easier to understand and 
no need to delete a routinely typed 'return'-key) h1/h2/h3 img (inline/left 
right center aligned) and a-href, only 1 level of bullits, and I 
think I can come along without numbered sections. I was thinking 
about mark-up delimiters on the beginning of the line like === ==+ 
==- ==* ==#   I kind of liked \note and /note or /code but everybody 
will forget if the first one will be fore or backslashed so I guess 
the indented version to produce code. Plus I want the markup to be 
from a css file. No need to make this within the script because the 
template/and a script can take care of where and which to link to. 
That's about it.

The structure of MD since v2 is a separation of scanner and emitter. 
'scan-doc will break text into a block of [style content] pairs. 
'gen-doc will take that block and turn it into something, most commonly 
HTML.


The features of your doc - using your ==+, ==#, etc. are in the spec 
of the parser. Loosely explained, the parser's rule 'resets' when 
it encounters a newline.  It defines a few paragraph types that copies 
chunks of text (including 'paragraph that consumes text AND single 
newlines).  The rest of the rule determines the paragraph style and 
expected paragraph type:

  "===" text-line (emit sect1 text)

Could just as easily be:

  "==+" paragraph (emit my-bold-paragraph para)



The way a document is presented is all in the emitter. Seems this 
is where you seem to be yearning for most control. My first motivation 
using MakeDoc was stripping it of any styles - I just wanted a minimum 
of HTML markup that could be embedded and properly moulded by CSS. 
In my script above, I iterate through the [style content] list and 
use 'switch to determine how to handle each, this should be sufficient 
for documents without any complexity. It's really then just a case 
of modifying the HTML that is emitted.



Example of script used in RSP (exposes [escape-html scan-doc gen-doc]):


  <link rel="stylesheet" href="http://ross-gill.com/styles/anywhere.css">
  <% do http://reb4.me/r/xhtml%>

  <pre><code><%= mold doc: scan-doc some-input-text %></code></pre>
  <%= gen-doc doc %>

How it looks depends on the stylesheet you use.

The thing is that MD markup is supported by quite some Wiki engines 
etc.

Scot, any markup could be parsed/processed by Rebol. So my question 
here was about the syntax/features.

I think you keep mixing up the implementation of processing any of 
these markups being done in Rebol (which you prefer, and I don't 
question this) with the actual markup.

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?

read join http:// second load/markup "<td>4.27.151.216</td><td>15551</td"

the whole page is generated with just this markup. 

<!page-header>
<!main-menu>
<center><img src="/images/under-construction.png"></center>
<!page-footer>

The styling mechanism is all up to you.  currently, the site is a 
mix of CSS, images and run-time html generation.


As I start adding dynamic content tags, I might start using some 
remark code within the CSS to keep the style programmable.


things like colors, texture-names, could all be resolved from remark. 
 Where and how that information is stored is totally separate from 
the engine.


remark tags are little dialects which are created & parsed dynamically, 
stored as sets, which are called document models.   Using a smart 
caching system and a feature I call "dialect Learning" you can *merge* 
different document models together and leverage code from a variety 
of sources.


In the above the <main-menu!> might generate markup containing remark 
tags which you define before or later, the menu will adapt its style 
for your needs.   so the same menu, will in fact generate different 
html output based on what mix of document models you are using.  
 one might build animated javascript, the other might be only static 
HTML.


the style is much more than just "looks" its actual content, but 
the nice thing is that your source HTML is totally unchanged, and 
there is no "Code" in your pages, only markup.

the <!main-menu> tag itself might return: <!TITLE item-1>  as part 
of its markup so that will ultimately use the p.title  CSS class.

can be diferent fonts too. IIRC he used 4 colors or so. or if nothing 
else helps some markup.

Thanks for suggestions. Have to look into that. Currently i have 
anti-colors, mostly because i box the words, not just colorize them. 
looks like suqeaks etoys :) to see it, run edit-tools in my developer-folder, 
open a script, choose color-rebol.r in the plugin-list and close 
your eyes quickly :)) more a demo how to markup text.

interesting point is, you give it a text-face, a start and end, and 
a template for markup and do:
  markup-face ta make markup-face! [color: local/2] start end
and then you have markup :)

Did you know you can do the whole markup with iterated faces? 1766 
markups ~8000kb.

Kinda ... out of the box XML is not 100% but   load/markup  may do 
what you want for some cases


If that is not sufficient, some rebols have written  extensions. 
  Umm, like John just posted.  :)

It is entirely possible to parse blocks into text markup, when you 
want to allow code to automatically generate its own document (that 
is a hierarchical source, source code)

Yes, the thing is to first agree on the markup to use. But we didn't 
make it to get the mentioned people to start working together towards 
one solution.

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.

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?

So, I have made some enhancements to MDP and put a beta online. You 
can find it at: http://www.robertmuench.de/download/make-doc-pro.r

The following changes have been made:
*Bugs fixed:*

#State tracking flags weren't correct, could lead to strange results 
when using tables where cell text used inline markup. Especially 
in site-mode.

*New Features:*

#Code can now be included via ~=include code <filename>~ where the 
included code will be automatically indented and hence handled like 
an example by the output format emitter.

*Programmatic changes:*
#Celeaned up the global word pollution (Thanks to Ahsley Truter)

#Renamed ~generate-files~ function to ~scan-doc~ to meet MD2 wording

I have been inspired by the make-doc line.  Robert's rendition is 
fantastic.  Love the whole site in one file thing.  Keeping the CSS 
out of the rendered html is good, using classes.


MDP-Browser sounds really cool.   a makedoc/spec browser for makedoc 
formatted scripts.


I have been playing with a document format that I call nulldoc, which 
is mostly a set of generaly rules about how plain text documents 
have been formatted traditionally, or how plain text copied from 
a web browser can look, and I started developing a set of broad regular 
expressions to markup plaintext.


based more on what I wanted than what I actually had, the rules I 
came up with go something like:

two blank lines begin a new nulldoc document (segment)
spaces/numbers/letters/symbols represent lists.

tabs/spaces at the beginning of the line denotes code/hierarchy. 
 

tabs that are trapped by non-space on both sides means tabular data.


I differentiate between code and hierarchy indentation by short-circuiting 
code switch with #:


	code section

#	numbered section


I wrote a web page that reads the KJV aloud using an MS Agent character. 
  Used a control from MS for a menu   I had it voice-activated, but 
that was a drag so I used "web navigator control"  stupid name for 
a menu.  I think it's still up at http://members.cox.net/rovingcowboy/kjv/
 probably won't speak unless you have sapi 4 voice installed, though.

Just a suggestion for Make-doc.. using some form of markup that would 
co-exist with CSS  check out http://www.csszengarden.com/

My opinion; makedoc2.r is the preferred RT markup engine.  I like 
to promote Gabriele's PDF-Maker as well.  For DocBase, you need to 
get used to wikitext.  Take a look at http://www.rebol.org/cgi-bin/cgiwrap/rebol/documentation.r?script=makedoc2.r
for a fairly complete view of the various tools at our disposal. 
 Some are awesome domain enhancing tools such as John's nicomdoc 
with the math extensions.

I use makedoc2 right out of rebol.org and one I call makecv, that 
strips out all the ardornment from the default template.  Orginally 
modified for a resume, comes in handy for a few things.  nicomDoc 
for that rare times I need math.  But to be honest, Mulch, the markup 
used in a lot of the rebol.org documentation is pretty nice; but 
to use it you need to document rebol.org <wink><wink>  Sadly, I'm 
now getting too used to wikitext from DocBase.

No. google on the term "online pdf proofing" Used by publishers and 
printing to let clients markup / approve pdfs online before going 
to press.

the pdf maker is not a markup language :) it's a (rather low level) 
dialect. you generally want to hook up higher level mls to it (like 
makedoc and qml)

a quick scan here ... I do not see anything for taking a .pdf and 
converting it to something like an image or some markup.  Does anyone 
know of something that converts a .pdf to generic postscript (like 
for GSView) or to convert to native REBOL format?  Thanks.

You can make it a little more complicated to add more markup types, 
but the basic structure is the same. The trick is the :a before the 
paren - otherwise it won't work, and you can crash older versions 
of REBOL.

markup-chars: charset "*~"
non-markup: complement markup-chars
tag1: ["*" "<strong>" "~" "<i>"]
tag2: ["*" "</strong>" "~" "</i>"]
parse/all data [
    any non-markup
    any [

        ["*" a: skip b: to "*" c: skip d: | "~" a: skip b: to "~" c: skip 
        d: ] :a (
            change/part a rejoin [
                select tag1 copy/part a b
                copy/part b c
                select tag2 copy/part c d
            ] d
        ) any non-markup
    ]
    to end
]

If you want to determine whether there have been any replacements, 
change the second any to some and parse will return true only when 
replacements have been made. Be careful to avois use of the markup 
characters in your replacement text.

Here's a simplified version of my example that can handle multiple 
instances of multiple markup types and be adapted to different end 
tags (thanks Tomc for the idea!):

markup-chars: charset "*~"
non-markup: complement markup-chars
tag1: ["*" "<strong>" "~" "<i>"]
tag2: ["*" "</strong>" "~" "</i>"]
parse/all data [
    any non-markup
    any [

        ; This next block can be generated if you have many markup types...

        [a: copy b "*" copy c to "*" copy d "*" e: | a: copy b "~" copy c 
        to "~" copy d "~" e: ]
        :a (change/part a rejoin [tag1/:b c tag2/:d] e)
        any non-markup
    ]
    to end
]

Here's what I have right now:

		markup-chars: charset "*_@"
		non-markup: complement markup-chars
		inline-tags: [
			"*" "strong"
			"_" "em"
			"@" "code"
		]

		markup-rule: [
			any non-markup
			any [
				[ a: "*" b: to "*" c: skip d: |
				  a: "_" b: to "_" c: skip d: | 
				  a: "@" b: to "@" c: skip d: ] :a (
					change/part a rejoin [ 
						"<" select inline-tags copy/part a b ">"
						copy/part b c 
						"</" select inline-tags copy/part a b ">"
					] d
				) any non-markup
			]
			to end
		]
		parse text markup-rule

If you want to guarantee progress with my and your examples (and 
better support multichar markup tags) change the last
  any non-markup
to
  any non-markup | skip
and that would do it.

okay, here's a slightly tweaked version that uses a multichar markup 
tag:

        markup-chars: charset "[*_-:---]"
        non-markup: complement markup-chars
        inline-tags: [
            "*" "strong"
            "_" "em"
            "@" "code"
            "--" "small"
        ]

        markup-rule: [
            any non-markup
            any [
                [ a: "*" b: to "*" c: skip d: |
                  a: "_" b: to "_" c: skip d: | 
                  a: "@" b: to "@" c: skip d: |
                  a: "--" b: to "--" c: skip skip d: ] :a (
                    change/part a rejoin [ 
                        "<" select inline-tags copy/part a b ">"
                        copy/part b c 
                        "</" select inline-tags copy/part a b ">"
                    ] d
                ) any non-markup | skip
            ]
            to end
        ]
        parse/all text markup-rule

Note that my last example keeps track of both the start and eng tags, 
even though I don't need to with the markup chars I used.

Well, if you want exceptions, you gotta code them in. In this case, 
before the block of your markup rules, as an alternate.

hm. Now I just need to figure out how to allow markup at the start 
of a line. I'll need to look at your code back there.

Petr.... you just reinvented erebol, rsp, .... build-markup?

Maarten - now looking into build-markup - sorry, it is just strange 
was of doing things .... noone will place rebol code into template, 
that will not work ... btw - the code is 'done? What happens if someone 
uploads template with its own code? I want presentation and code 
separation.

In this case you may also look at load/markup ;)

what Volker said.


s: "<good tag><bad tag> 3 > 5 <other tag><good tag with something 
inside>"
b: load/markup s
while [not tail? b][
	either tag? first b
		[ either find/match first b "good tag"
			[print first b]
			[print rejoin["X" to string! first b "X"]]
		]
		[print first b]
	b: next b
]

I think there is some limit in load/markup - I would not used it 
for large data

I came up with a rule:  [some [thru "<td" thru ">" y: to "</td>" 
(a: remove-each tag load/markup y [tag? tag])]]  but it seems to 
not be as efficient as it could be.

Josh, if you do a load/markup on the whole string, you get a block 
with tags and strings. You can then pick the string from the block, 
maybe doing TRIM on them to sort out newlines and spaces. Like:

blk: load/markup your-data
foreach f blk [if all [string? f "" <> trim f] [print f]]

foreach item load/markup xml [if not tag? item[ print item]]

I have this code which does this:

cmd-txt: "unasg"  cmd-term: "<"

pre-txt: "unasg"  pre-bgn:  "<pre>"               pre-end: "</pre>"

rsp-txt: "unasg"  rsp-bgn:  {<span class="eval">} rsp-end: {</span>}
site-url:	http://rebol.com/r3/docs/functions/try.html

page-txt: to-string read site-url
probe parse page-txt [thru pre-bgn copy pre-txt to pre-end]
probe parse pre-txt  [copy cmd-txt to cmd-term]
probe parse pre-txt  [thru rsp-bgn copy rsp-txt to rsp-end]

print [{"cmd"} "{" cmd-txt "}"]
print [{"rsp"} "{" rsp-txt "}"]

will yield this:
cmd

 { if error? try [1 + "x"] [print "Did not work."]          <-- this 
 is close to what I want to do
}
rsp
 { Did not work. }


This is close to what I want, but it is not foolproof.  For example, 
I would like to capture all displayable text that is separated from 
any html tags.  In my code example, if a displayable greater than 
symbol  < was displayed, then the parse would stop prematurely.


I am guessing someone has already created some code to "pull apart" 
a html web page, separating displayable text from invisible markup 
code.

load/markup

more to what Graham is saying is, try...
>> load/markup http://rebol.com/r3/docs/functions/try.html


you will be returned a block of strings and tags, which you could 
use the tag? word to test if each element is a tag or not to seperate 
HTML from regular Strings.

Chuck Moore uses color extensively in his color forth .. to replace 
other types of syntactic markup.

there might even be some java there too that transforms the wiki 
markup to xml

and for your script:
print "Content-type: text/html^/" 
read-cgi: ...
args: decode-cgi read-cgi 
template: {
 <html><body> <pre> <% mold args %> </pre> </body></html>
}
print build-markup template

i once tried such a source-thing. was cool, browsing with kind of 
anamonitor and jumping right to the source from there. but without 
native support needed ugly hacky markup. if native, one could jump 
from a face straight to its sourcecode.

we have looked at it and at the same time looked at phpsavant 
 http://phpsavant.com/yawiki/index.php?page=StartExample


for us, our key concerns is maintenance from the developer point 
of view. We want the team to stick to one language (or markup)... 
there will be times in a project, that you may not have the luxury 
of a designer...so the developer still end up working on the apps 
GUI (or look-n-feel).

Divs are ultimately more flexible than tables.

Tables have their place -- for the display of tabular data as they 
were intended.
For page layout and markup, DIVs are ultimately less boxy.

They also, usually, produce data flow that is more friendly than 
tables for people using accessibility aids.

foreach item load/markup read http://www.rebol.com[if string? item 
[print item]]

load/markup...  That's it...

Tex .. need to mark up everything.  This way I avoid writing the 
markup .. Rebol will do that for me.

With QM, I use QuickTags (integrated into RSP or standalone) to build 
the form elements, and then wrap common constructs in functions.for 
data-driven forms.  It's not as pure as say, Henrik's HTML dialect, 
but perhaps has the flexibility of being at markup level.

http://www.ross-gill.com/page/QuickTags


Alternatively I have a make-doc dialect (somewhat rough) that I use 
for forms on my site wiki.

http://2008.rebolconf.info/on/!Edit_Form?format=raw

Depends to what degree you use html to define visual aspects.  The 
comparison above is talking old school page design where your markup 
contains all the bgcolors, widths, font colours, etc. (FrontPage-esque) 
 Typically this approach does significantly increase page size.  
Using tables mainly as an alternative to <div> as a way to divide 
up page components in an otherwise CSS driven design isn't going 
to be at all costly in comparison.  Actual bandwidth cost I guess 
is case specific.

Interesting pov onto website creation - http://24ways.org/2009/make-your-mockup-in-markup

my friend works the opposite way - design proposals are done in Photoshop, 
then he cuts it into the markup .... (sometimes wondering it "feels" 
differently to what he originally did in Photoshop :-)

REBOL Text Markup Dialect (TMD) for color-text in REBOL:
www.rebol.net/notes/textmarkup.html

New website ( http://policywatch.org.au) generated 100% from my 
new HTML/CSS/JS/jQuery markup language ... MML (Meta Markup Language). 
More details to follow once the election is over! ;)

my tool currenctly loads 1MB of xml tags in under a second.  its 
almost as fast as load/markup.

REBOL's built in BUILD-MARKUP function can also be a good choice.

Which was the first apss at RSP (1 of 2 choices) I handede to Carl. 
I think build-markup does only support <%= %> not <% %> (which I 
always found a pity)

format-xml: func [ xml
    /local out space prev
][
    out: copy ""
    spacer: copy ""
    prev: copy </tag>
    foreach tag load/markup xml [
        either tag = find tag "/" [
            ; we have a close tag
            

            ; reduce the spacer by a tab unless the previous was an open tag
            either not tag? prev [
                ; not a tag
                remove/part spacer 4
            ][
                ; is a tag
                if prev = find prev "/" [
                    ; last was a closing tag
                    remove/part spacer 4
                ]
            ]
        ][ 
            either tag? tag [
                ; current is tag
                ; indent only if the prev is not a closing tag
                if not prev = find prev "/" [
                    insert/dup spacer " " 4
                ]
            ][
                ; is data
                insert/dup spacer " " 4 
            ]
        ]
        repend out rejoin [ spacer tag newline ]
        prev: copy tag
    ]
	view layout compose [ area (out) 400x400 ]
]

obj2xml: func [ obj [object!] out [string!]
	/local o 
][
	foreach element next first obj [
		repend out [ to-tag element ]
		either object? o: get in obj element [
			obj2xml o out
		][
			repend out any [ o copy "" ]
		]		
		repend out [ to-tag join "/" element ]
	]
]

Geomol: funny, I'm currently trying to port one of my Python project 
to Rebol : a markup langage with html/latex output !

Geomol: I've been misunderstood : I was asking if you can output 
a LaTeX doc from your markup engine.

markup: ["**" "strong" "//" "em" "__" "u" "--" "del" "^^" "sup" ".." 
"sub"]

foreach [bal html] markup [format text bal html]

REBOL has a build-markup function.

You have build-tag, to-tag and build-markup.

Functions to help you make markup text.

build-markup "toto<%a%>"

I've never used build-markup, I just realize.

Hi.  Just to thank to all of you who helped me starting with REBOL. 
My markup engine is getting better now. I even build a little page 
with it : http://kib2.free.fr/REBOL/index.html

Hi. I've got a local variable "level" inside an object, defined has 
follow : "level: length? t".

If I try to print it, no problem. But  if I use "build-markup {<%level%>}", 
REBOL raises a "ERROR no-value in: level". Any idea ?

Is your build-markup call outside the object? If yes, then you have 
to refer to level as object/level (where object is the name of your 
object).

o: make object! [t: "abc" level: length? t]
build-markup {<%o/level%>}

Geomol: no build-markup is called within my object. But I forget 
to say that I use "return build-markup {<%level%>}"
I don't know if I can "return" local vars ?

>> o: make object! [t: "abc" level: length? t f: func [] [return 
build-markup {<%level%>}]]
>> o/f
== "***ERROR no-value in: level"

heh, funny! :-)

Right. WOuld be nearly another kind of markup for most things. This 
computed gotos may not work, but the rest should.

Having everything wrapped in HTML (or XML or whatever markup-language) 
is not a good solution. I hate using applications inside a browser, 
because they're always slooooow. Native application clients are much 
better. Think reblets!

With an architecture where the presentation code is written purely 
in code, and not a combination of code and markup, and is delivered 
as a single simple download to run in a real language runtime, then 
things can be simplified significantly.

why do the term semantic and markup used in the same sentence seem 
like an oxymoron to me?

You mean the sentence: "adding semantics to markup to take it from 
being machine readable to being machine understandable." ? To me 
all markup languages are machine redable, at least when I use Rebol:-)

It seems a short-sighted attempt at paving the cowpaths.  I appreciate 
the want to hardwire some of this stuff, but who decides and where 
does it stop?  I'd far rather xhtml was cleaned up, that there is 
one markup language that allows for a lot with a basic set of building 
blocks.

That should read 'that there is *at least* one markup language...', 
not that there is only one markup language.  One of the commenters 
suggested instead of inventing new tags for roles, why not have a 
'role' attribute that serves the same function?  That way you can 
expand the list of roles without brewing tag soup...

Probably build-tag or build-markup.

TeX is a markup system, kind of like HTML. you can produce PS documents 
from TeX files.

is there someone who have an idea for printing in rebol on a dot 
matrix printer ? i have to pilot it for printing a pre formated bill 
for dental care.  If anybody see what i mean..  I was wondering about 
how to do it in rebol, by passing by a markup langage but i dont 
know how it work.  if anybody got an idea...

I'm working on a Print Markup Language for a customer, that will 
output the REBOL postscript dialect, so it can produce PostScript 
and PDF output. When producing text, it's possible to specify centered 
and right-aligned text by using the words CENTER or RIGHT after the 
text followed by the size of the area, wherein the text should be 
aligned. Example:

at 100x100 "Right-aligned text" right 400

has the same effect as:

at 500x100 "Right-aligned text" right 0


Suggestion: The dialect will be more simple, if the size is dropped. 
Then the position (from AT) is the right border of the text on the 
output. Same for CENTER, where the position will be the center of 
the text.


I know, Henrik use this dialect. What do you say? If others use this 
dialect, I would like to hear your opinions! If I change this in 
the dialect, it may mean changes to your code.

launches View but doesn't open the file

 here it launches, IIRc it did that immediate without me setting something 
 (now i prefer editor by  default, so cant check).

and by .r I mean a link that is actually a wrapper with all the crap 
needed to know what to do

 AFAK that is some html-markup, not *.r-created. On IE the plugin 
 installs automatically, on firefox that will come.

And plugins and mime are two things, plugins run inside the browser 
and need some marku (AFAIK), mime-types are launched by  external 
apps (rebol if the server says its application/x-rebol)