Not much to do with content, but some sort of syntax highlighting (even just bold-facing keywords or something) would make longer code samples on such a site much more readable -- both for Arc and Scheme snippets. At least to me. There's still the sect of people who are too manly for syntax highlighting or whatever, so you could have a link at the bottom of codeblocks to toggle it.
This also applies to inline fixed-width fonts, which you should have as well. It's annoying as hell to have a billion conventions for inline code here: some people 'quote, others "quote", you could italicize, some don't do any formatting, and sometimes I just get lazy and put it
in its own block.
A sane syntax for this would be good. I'm never sure if arc-globals* interact well with the italicizing syntax (asterisks) in different contexts: (= global 5)*?
I would have a simple method for getting the code in plain text, but I wouldn't bother including dependency handling natively. I feel like all dependency checking could be done with extra code in the snippet and handled on the client side. That would be simpler and more open to changes in the future. Plus we don't have to spontaneously create a system that is both simple and comprehensive enough to satisfy everyone simultaneously ;)
Basically I would extend the news.arc code to include support for another item type - code - that can be submitted separately, named, searched for, and retrieved as plain text. Then all of the comments/discussion is included for free, and if the double indent was made slightly more intelligent it could extract code snippets from normal comments as well.
It doesn't seem like it would be too hard to implement this way (most of the code is already there) and if we can get pg to like it he might update the arc forum to support it ;)
Forgive me if, lately, my posts seem overly Clojure related, but after seeing your post my first thought was that clojuredocs.org might provide some inspiration.
I actually tried GitHub Pages for awwx.ws before I changed to hosting it myself. I don't know if this is still true, but at the time they rendered pages as a batch process: I'd make a change, and some indeterminate time later -- sometimes immediately, sometimes after a long delay -- the change would appear on my web site. I found this killed my productivity.
At this point I'm willing to put in the time to implement a solution that works the way I want it to.
However I wouldn't discourage anyone from setting up a GitHub Pages for Arc today. I hope that my site will turn out to better than GitHub Pages (for this particular purpose), but that doesn't mean that you need to wait around for me to implement something, or even necessarily that you will in fact find my site better than GitHub Pages.
Anything that gets published on GitHub Pages I can import into my site when I actually have something written, so any work you do now in GitHub Pages won't be lost if it turns out that my site does work better. And GitHub Pages are really easy to use and get started with, so there isn't a big time investment needed there either.
