Home

I’ve started the development of the next version on January 2010.
I still don’t know if it’ll be version 3, or 2.3: we’ll see.
The next version will be 3.0, due to some changes incompatible with previous versions.

Goals for the next version:

1. refactor the code so that functions get smaller and easier to understand
2. change the directory structure of the project, so that other developers can join more easily
3. extract code from chili.js into independent files under src; then update build.xml to concatenate them again into chili.js
4. integrate the global Chili object into a property object of jQuery, like jQuery.chili.options
5. rename recipes; example: instead of recipes.js use jquery.chili.recipes.js, instead of php.js use jquery.chili.php.js
6. fix line numbering, which now breaks after a multiline comment (…examples/geshi1.0.7.22-n.html)
7. make each recipe a real jquery.chili plugin; this way recipes.js will be created by concatenating plugins
8. make chili compatible with jQuery 1.4
   In previous versions of jQuery, JSON evaluation went through eval, but now it goes either through a built-in JSON object, if available, or the “new Function()” workaround. When using recipes loaded by ajax, the new JSON evaluation generates a parse error and nothing gets colored.
9. instead of <pre><code>...</code></pre> use <code></code> alone this is not ‘cleanly’ possible due to IE not honoring new lines (\r) when reading text from a DOM element X whose white-space is not ‘pre’ right into the HTML source. There are two ways in IE for setting white-space to ‘pre’ for X, right into the HTML: 1- by putting X inside a PRE; 2- by setting the CSS of X. Users can choose what they prefer, Chili won’t care.
10. instead of &#160;<br /> and   use real newlines and spaces respectively this is not possible due to IE not honoring new lines (\r) when setting the innerHTML of a DOM element
11. move ln- class to CODE. This implies changing the schema for adding metadata.
    1. use chili-lang-php instead of just php
    2. use chili-ln-1, instead of just ln-1
12. improve the configuration options. For example, make the selection window optionable
13. implement user filters, so that the user can customize Chili’s output: {:filter()[...some code here...]filter:}
14. use <li>, instead of &nbsp;<br>, and style <pre><code><ul> so that no bullets are shown I’ve undone this one again, because there is no real reason for adding line numbers overhead when no line numbers are required; also user filters are simpler to write
15. rework the coloring engine using RegExp.exec() instead of String.replace();
16. allow recipes to control the matching loop
17. add unit tests
18. fix the PHP recipe
    Currently the recipe doesn’t work properly when recipes are loaded by ajax. The culprit is this instruction:
    var html = this.x( no_php_2, 'html' );
    In fact, if the html recipe is still to be downloaded, then the html variable becomes equal to no_php_2 instead of the transformation of no_php_2 by means of the html recipe. This will ultimately cause a replacement that wipes out all previous replacements.
19. improve all the recipes so that they pass tests like Tricky Code Snippet From Hell
20. improve the documentation
21. make it easier for contributors to publish their own recipes

Notes about the next version

• maybe it’s worth making a better object with a recipe; I mean, we could take the recipe JSON object and add methods and properties to it so that we can later call methods on it like: recipe.hilite(text)