pcs / static / index.html

Full commit
<!DOCTYPE html>

<title>Processing CoffeeScript Editor</title>

<link rel="stylesheet" type="text/css" href="/style/style.css"/>
<link rel="stylesheet" type="text/css" href="/style/jquery-ui-1.8.13.custom.css"/>
<link rel="search" type="application/opensearch+xml" href="/static/opensearch.xml"/>

<script async="true" src="/lib/processing.min.js"></script>
<script async="true" src="/lib/coffee-script.min.js"></script>
<script async="true" src="/lib/codemirror.min.js"></script>
<script src="/lib/ender.min.js"></script>
<script src="/lib/pcs.js"></script>

    <a class="button navbar-show" title="Show Navbar [alt+h]">
        <span class="sprite s_bullet_arrow_down"></span>
    <div id="viewNav">
        <div class="buttons-left" > </div>
        <input type="text" class="script-path" spellcheck="false"></input>
        <div class="buttons-right" > </div>
    <canvas id="canvas"></canvas>
    <div id="editor"></div>
    <div id="gallery">foobar</div>
    <div id="help">
            <h3>How do I write pcs scripts?</h3>
            <p>pcsedit uses CoffeeScript and processing.js. You should
			at least be familiar with CoffeeScript, which shouldn't be
			to hard to pick up if you know JavaScript.

			You can look up all available functions provided by
			processing.js in the reference. The pcs environment does
			have some quirks though. Processing.js variables, such as
			<code>width, height and mouseX</code> are only set once
			during the loading of the script. This is not so tragic for
			width and height, but if you want to access the current
			mouse position, you need to access it via the
			<code>pcs</code> object. <code>pcs.mouseX</code> will always
			give you the current x coordinate of the mouse. 
			You can also write modules which can be imported via the
			<code>require("/path/to/script")</code> function. It will
			return whatever is assigned to the <code>exports</code>
			variable in the imported script.
            <h3>Why can't I use tab/2 space indentation?</h3>
			<p>Because I'm mean. Really though, I want to keep the
			editor simple and have chosen what I think are sensible
            <h3>How come I can edit other peoples scripts?</h3>
            <p><b>You can't</b>. The changes to other peoples scripts
			are <b>browser local</b>.<br/>
            Local changes are lost once you leave/refresh the site, so
			you need to <b>copy</b> the script if you want to save your
            <h3>Can I keep my script private?</h3>
            <p><b>No</b>, all scripts are public under cc-by.<br/>
            Unless otherwise specified in the source code, all content
            you publish to is licensed under 
            <a href="">
            CC-BY 3.0 (Creative Commons Attribution)</a>.
            <h3>Isn't this an <a href="">XSS</a> nightmare?</h3>
            <p><b>Yes!</b> In the worst case, all of your scripts could be wiped out. <br/>
            Take care which scripts you run. If you want to
            <code>require()</code> a script and don't trust the owner to
            keep his script safe, you should copy it and use your own version.
            <h3>Can I load images/3d/audio ?</h3>
            <p>Images work, but may only be available after a few ms of
            running the script.
            3D works if <a href="">
            your browser supports WebGL.</a>
            There are some restrictions regarding calling of size(), which
            are documented <a href="/#edit/mbarkhau/">here</a>.
            Support for audio is untested.
            <h3>Why don't you prevent bad code?</h3>
            <p>Because that would be a cat and mouse game. Better to make
            people aware of the problem than to give them a false illusion
            of safety.<br/>
            We are working on a function to flag bad scripts and rate good
            ones. In future we may also validate a safe subset of functionality.
            <h3>Can I run my .js or .pde scripts?</h3>
            <p>Not atm. but it shouldn't be too hard to get working.</p>
            <h3>This sucks, eclipse/vim/emacs is way better!</h3>
            <p>Sure, but you have to install those. A common theme in online
            courses is to spend the first lesson setting up the students local
            development environment. If students aren't there by compulsion,
            but attend voluntarily, you have set up a barrier and lost 90% of
            your potential audience. <br/>
            With pcs, you just give them a link and they're on their way.
            The primary goal for pcs is to make it dirt simple for people
            to start editing code while keeping some of the comforts of the
            better editors. These include syntax highlighting, a tight
            edit-run loop, (just press alt+r), code completion (ctrl+space)
            and documentation within the completion menu.
            <h3>This is awesome, can I help out?</h3>
            <p><b>Of course!</b> Code can be found at
            <a href="">