World: r3wp

aren't  = ain't

yes you is!

Thanks Sunanda. I wasn't aware one could define it's own CSS for 
library code display.


However Gabriele's emitter has very usefull tags that are missing 
in the current library emitter. In particular, it is posible to highligh 
differently standard Rebol words and new words. This is extremely 
usefull for a beginner like me who doesn't yet know all of Rebols 
vocabulary. There is also the TAB tag that helps a lot.


Unfortunately, writing a new emitter using Gabriele's code is beyond 
my ability.


And from the dreamer in me... here is a suggestion for this better 
emitter: 

When one clicks (or maybe hover) on one of the standard Rebol words, 
you are presented with it's definition.

That's a nice idea for a sort of "REBOL explainer" application.
But it would be difficult to do in the Library.

The Library does attempt to load and parse scripts -- that's how 
we do the colorisation. But (as with Gabriele's code) we rely on 
REBOL's own reflective abilities to tell us what is a word, function, 
operator etc.

The Library runs an old version of Core (and even if we update that, 
we'd never run a version of View on a webserver) so it does not have 
access to all the information a proper explainer.highlighter would 
need.
Take this script for example:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?color=yes&script=reboldiff.r

'new-line is a valid REBOL word, but it is not colored: that's because 
it is not a word in the version we use.

So sadly, the colorisation at REBOL.or remains a nice bit of eye 
candy rather than a solidly dependable feature.

REBOL's scopeless binding makes it VERY hard to analyse code without 
actually evaluating it... which can be pretty dangerous.  :-(

That's true -- not something we could do safely on a server.....Hence 
we are limited to load/header etc.

A desktop application may be able to be more daring -- provided you 
don't let arbitrary code out of the sandbox.

I understand about the "Rebol Explainer" app. ... maybe someday in 
a Rebol IDE.


But are the enhancements "� la Gabriele" still possible (i.e. Keywords, 
Words, and Tabs tags ) ?

Jean: did you try overing on a bold word in my output? :)

Sunanda: i keep the list of know words external to the script. there's 
a link to it from the html doc i posted (look for the #include directive 
and click on it). there's also a script that generates that file 
(apache directory index is enabled for that dir, so you'll be able 
to see it there)

Gabriel -- Thanks....A word list sounds a good way to go.
***

Jean-Francois -- a hover-over on kewords is certainly do-able and 
could look fun for the first couple of minutes on colorised scripts. 
Though it has drawbacks:
** it'd just about double the size of the page

** I think I'd be serious annoyed by it after 30 seconds -- though 
that may just be me

** lots of hidden-by-css styles (that's the way I'd do it, usng some 
of Eric Meyer's clevernesses) could create confusion for anyone using 
an elderly web browser or screen reader.


A good step in the right direction would be better styles for the 
code as we display it now.....So anyone experimenting with that is 
doing us all a great service ... Amd it would pave the way by creating 
a better foundation for higher cleverness.

Gabriele, That is great !

I hadn't noticed the extra info poping up. Just that simple extra 
info is very helpful when inspecting/reading code (well for me anyway). 
Thank you.

The fact I hadn't noticed it might be a counter argument to Sunanda's 
fear of being annoyed by it. You really have to leave your pointer 
on it.


Any new language (natural or artificial) feels like "Scriptio continua" 
( http://en.wikipedia.org/wiki/Scriptio_continua) 

at first and all these visual cues are very helpfull in building 
the program's tree in your mind.


Imagine yourself a beginner at german reading a text that would have 
been colorized to accentuate its different elements. Hovering over 
a colored word would give you a translation or even maybe just a 
picture to prevent you from thinking in your first language.

I got some time to look at the CSS style sheet for displaying script 
code, Jean-Fran�ois asked for. Where is the CSS located?

Is it the look of the code in this document: http://www.colellachiara.com/soft/PDFM2/pdf-maker.html
that is asked for?

The personalised CSS feature starts here:
http://www.rebol.org/cgi-bin/cgiwrap/rebol/css-available.r

Use the menu bar to explore the options [Preview page � Update � 
View system CSS � Switch to system CSS � CSS help]
Have fun!

Does anyone have an opinion on what colors to use in syntax highlighting? 
The color-code.r script by Carl produce these colors: http://home.tiscali.dk/john.niclasen/rebol/color-test.html

This is how vim color REBOL code: http://home.tiscali.dk/john.niclasen/rebol/color-test-vim.html

Can't seem to hit those John.

That's great Geomol.
Yes the pdf-maker docs are a good example.
I would stick with gabriele's color for a start.

Gregg, the Tiscali server (or network) was a bit slow last night. 
Try the links again, if you had trouble.

You guys can also think about, how many different colors are needed 
(preferred), when displaying REBOL source. A color for comments, 
values, datatypes, words, etc. Should values be split into numeric 
values, series and others with each their color. Other things?

personally id go for minimalist hilighting with colouring only for 
comments and strings - any more than that and it starts to look like 
a fairground -)

I programmed in COBOL for many years without coloring. Then I started 
using vim, and I found, it looked weird with all those colors. After 
a while, I started to really like it, because it's so much easier 
to read the code. Colors make our brains look and distinguish components 
much better than words. I'm for colors. But they have to be balanced, 
so it doesn't hurt the eyes too much.

So did !
The color styles used right now are here:
http://www.rebol.org/cgi-bin/cgiwrap/rebol/css-view-system.r
(search for colorizer)

We already (in effect) collapse some into the same color: like file! 
and email!  Perhaps url! should be the same color too.

One of my heroes, Chuck Moore found colour important enough to use 
it for

'meaning'.  He got rid of colons in ColorForth by using bluespace 
and redspace and
greenspace instead of just whitespace.

Trouble with colour is that some people are colour blind.

For some of them (and therefore all of us) using [red/green] to mean 
[danger/safe] or [stop/go] is dangerous.

Which is why (at least where I live) green traffic lights have been 
slowly migrating towards bluey-green over the past couple of decades.

Good points.  And Charles had some trouble with 'printouts'.  :) 
 I stopped following
the progress quite a few years ago.

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

I prefer the color-code scheme over the VIM scheme (don't like the 
pink), but as long as it isn't too bright most anything should be 
OK. 


It would be interesting to do some research on using different rendering 
schemes for code, based on activity. For example, when writing and 
maintaining code, I like comments in gray, so they "fade out" a bit; 
but if you're reading code, in a Literate Programming sense, you 
probably want the prose to stand out and the code to be subordinate.

Or if you're looking for specific datatypes, have a hot-key that, 
when pressed, highlights them.

Weirdo

:)

I've thought that same thing a few times.  A "gork" button.

gork = grok

Sorry for clogging the channel...It must be the Hare Krishna rock 
band I've got playing

in the background while doing LibDesk2 design thinking...  I think 
LD2 might be
pretty cool.

Ooooh, a grok button. I like that.

Some syntax colors: http://www.fys.ku.dk/~niclasen/rebol/syntax-color.html

This is work in progress! First is colors for comments and values 
(as I suggest). Then colors from Carl's script color-code.r, then 
some named colors from REBOL, and last some JavaScript syntax colors, 
I found on the net.


Syntax colors for many languages seem to use green for comments. 
I prefer blue, so comments better stick out, also for people having 
trouble with red and green. Values being red seem to be widely used. 
I'll try to make an example of REBOL code with colors...

First example with test of colors: http://www.fys.ku.dk/~niclasen/rebol/example.html

My idea is to build an example, that satisfies the need. Then I look 
at implementation for the Library, so sources in the library can 
be viewed this way.


Maybe refinements shouldn't be that yellow!? Should background be 
a little gray like this? #f9f9f9 Or should it be white? The purple 
and blue might be a bit too bright compared to the red and green? 
Or should the red and green be brighter?

Also try select the text in the browser. What color does the different 
browsers and OSs use for highlighting text? Can the colored text 
still be seen, when it's selected?

OS X has a default palette of rather bright colors for highlighting 
to choose from, suggesting the text colors to be dark, so the text 
still can be read when selected.

Nice set of subtle colours!

On my Win-based machine,  all selected text is the same colour....white 
text on dark blue (though that is configurable)
***

A thought: if instead of FONT tags  you could switch to CSS. Then 
your experiments could use the same class names as the Library. Implementing 
that as your personal CSS on REBOL.org would be trivial

Ok, I'll look at the Library class names. Thanks!

Very cool stuff John...

I have to say that comments should be light gray, a web common practice.

Yes, I'm trying that out with gray comments. A good idea. Should 
known words (the words REBOL deliver in system/words as default) 
be green or blue, now comments aint blue?

I find when I have to correlate something to colours or  patterns 
it is better to start with the patterns first.


Since there are really only a few colours people can distinguish 
against white (or black) we can just like them hour:

Black = Structure, brackets, etc.
Gray = Comments
Dark blue 
Light blue
Red 
Pink
Purple
Dark green
Light green
Brown
Orange
Yellow (perhaps)

More subtle colours cause confusion.  

You also have Bold and Italics to consider.

I would use these to show "new" items (bold).
Also, you can do white on colour (BG).

like them hour
 should have been "list them here" (yes, I'm insane!)

In general you want to have it such that if everything is good, there 
is little colour distinction.  

For example most everything is black, gray, and dark blue.


The stranger the colour, the stranger of something you are trying 
to pull off in code.  Red should mean the parser is totally confused 
for example.  Or that the code is not actually code, but something 
that looks like code but is actually data.  That type of things.

Comments could be italic. We're used to, that we can skip italics 
in text, I think.

In ConText, I use bold+blue for for branching and a few other important 
funcs (if, either, all, etc.), navy for other funcs, green for datatypes, 
red for numbers, dark red for strings, gray for comments; brackets 
are dark gray, but go black to show matching pairs when you're on 
one.

My thinking behind the bold+blue was driven by the concept of cyclomatic 
complexity (McCabe), and making things jump out that indicate complexity 
in code. I know if I see a lot of bold+blue stuff on the screen, 
I either need to think real hard, or rewrite it. :-)