code-illuminated - Project Hosting on Google Code

Earlier this year Sep 13, 2009 issue 16 (#docs/docs.js#0 becomes #docs/docs.js%230 in safari) commented on by neonstalwart - i made this change and another change in App.navigate so that it doesn't hide the page if a link from the TOC is clicked. i'm providing a diff attached to this comment. let me know if i need to sign something to be able to contribute this to you. thanks, ben... i made this change and another change in App.navigate so that it doesn't hide the page if a link from the TOC is clicked. i'm providing a diff attached to this comment. let me know if i need to sign something to be able to contribute this to you. thanks, ben... Sep 05, 2009 issue 16 (#docs/docs.js#0 becomes #docs/docs.js%230 in safari) commented on by neonstalwart - in case it's not clear... i should mention that i'm referring to the layoutchange branch in case it's not clear... i should mention that i'm referring to the layoutchange branch Sep 05, 2009 issue 16 (#docs/docs.js#0 becomes #docs/docs.js%230 in safari) reported by neonstalwart - in safari, links which have an href like #docs/docs.js#0, become #docs/docs.js%230 when you click on them. these types of links work in FF and these are the only 2 browsers i've tried. perhaps you could use #docs/docs.js/0 as an alternative but i haven't confirmed that it will work consistently. the fix is just a simple matter of changing line 171 of docs/docs.js to create a different string for the anchor. in safari, links which have an href like #docs/docs.js#0, become #docs/docs.js%230 when you click on them. these types of links work in FF and these are the only 2 browsers i've tried. perhaps you could use #docs/docs.js/0 as an alternative but i haven't confirmed that it will work consistently. the fix is just a simple matter of changing line 171 of docs/docs.js to create a different string for the anchor. Jun 22, 2009 2 new revisions pushed by sander.dijkhuis - Revision 0178e48406:Merge the syntax highlighting and CSS changes from the default branch. Revision f7b947e368:Add an experimental table of contents to each page It doesn't work everywhere yet, and contains some bad hacks. Also modified some other parts of docs.js to improve its doc structure. Revision 0178e48406:Merge the syntax highlighting and CSS changes from the default branch. Revision f7b947e368:Add an experimental table of contents to each page It doesn't work everywhere yet, and contains some bad hacks. Also modified some other parts of docs.js to improve its doc structure. Jun 11, 2009 issue 13 (Code blocks have incorrect spacing) commented on by sander.dijkhuis - Merged the fixspacing branch into master (revision 3ed92b44bf), still without solving the problem for IE. Alberto mentioned my fix didn't work well in IE8 either, so it's probably not the right solution yet. Merged the fixspacing branch into master (revision 3ed92b44bf), still without solving the problem for IE. Alberto mentioned my fix didn't work well in IE8 either, so it's probably not the right solution yet. Jun 11, 2009 Revision 3ed92b44bf (Fix the code block spacing issue 13 for most browsers, excep...) pushed by sander.dijkhuis - Fix the code block spacing issue 13 for most browsers, except for IE. Fix the code block spacing issue 13 for most browsers, except for IE. Jun 11, 2009 issue 15 (Merge Ubiquity's Code Illuminated) Status changed by sander.dijkhuis - The CSS changes fetched from Ubiquity's dab03fd22df0 revision have been merged in revision f3a64ec916. Status: Started The CSS changes fetched from Ubiquity's dab03fd22df0 revision have been merged in revision f3a64ec916. Status: Started Jun 11, 2009 2 new revisions pushed by sander.dijkhuis - Revision 029fb05d2a:Add a site title to the top. Revision f3a64ec916:Merge improvements from Ubiquity's documentation CSS file. There are new definitions for .documentation pre, .intra-wiki and a. We still don't have exactly the same versions: the Google Code repository has some better cross-platform font choices. Revision 029fb05d2a:Add a site title to the top. Revision f3a64ec916:Merge improvements from Ubiquity's documentation CSS file. There are new definitions for .documentation pre, .intra-wiki and a. We still don't have exactly the same versions: the Google Code repository has some better cross-platform font choices. Jun 11, 2009 issue 15 (Merge Ubiquity's Code Illuminated) reported by sander.dijkhuis - Ubiquity's version of Code Illuminated contains some improvements that aren't in the Google Code repository yet, like better link formatting and new parser infrastructure. Currently there seem to be too much differences for an automatic merge. https://ubiquity.mozilla.com/hg/ubiquity-firefox/file/tip/ubiquity/scripts/docs Ubiquity's version of Code Illuminated contains some improvements that aren't in the Google Code repository yet, like better link formatting and new parser infrastructure. Currently there seem to be too much differences for an automatic merge. https://ubiquity.mozilla.com/hg/ubiquity-firefox/file/tip/ubiquity/scripts/docs Jun 11, 2009 issue 14 (Automatically replace dumb quotes and multiple dashes) reported by sander.dijkhuis - I think we should automatically try to change dumb quotes (`, ' and ") into smart ones (&lsquo, ’), and multiple dashes (-- and ---) into en and em dashes. For the quotes, we should try to find matching pairs. We should avoid replacing the quotes and dashes within <code> and <pre> elements. I think we should automatically try to change dumb quotes (`, ' and ") into smart ones (&lsquo, ’), and multiple dashes (-- and ---) into en and em dashes. For the quotes, we should try to find matching pairs. We should avoid replacing the quotes and dashes within <code> and <pre> elements. Jun 11, 2009 issue 13 (Code blocks have incorrect spacing) commented on by sander.dijkhuis - Revision ce9f93f657 is another attempt to fix the issue. It seems to fix the layout well for IE8, but in the IE7 'compatibility mode' I still get incorrect spacing. Adding extra padding to each code block may help, but may also break the layout. By the way, I'm just adding blank lines to the code blocks without exactly knowing why they're needed. It might not be the correct way to do it at all. Revision ce9f93f657 is another attempt to fix the issue. It seems to fix the layout well for IE8, but in the IE7 'compatibility mode' I still get incorrect spacing. Adding extra padding to each code block may help, but may also break the layout. By the way, I'm just adding blank lines to the code blocks without exactly knowing why they're needed. It might not be the correct way to do it at all. Jun 11, 2009 Revision ce9f93f657 (Try another method: append a real new line to each code bloc...) pushed by sander.dijkhuis - Try another method: append a real new line to each code block. This fixes the issue for IE8 too, but not yet for IE7. Try another method: append a real new line to each code block. This fixes the issue for IE8 too, but not yet for IE7. Jun 11, 2009 issue 13 (Code blocks have incorrect spacing) commented on by albertosantini - In FF 3.0.10 it is ok. In IE8 (on Vista) the code blocks are separated by blank lines. In FF 3.0.10 it is ok. In IE8 (on Vista) the code blocks are separated by blank lines. Jun 10, 2009 issue 13 (Code blocks have incorrect spacing) Status changed by sander.dijkhuis - As Alberto noticed in chat, this is likely caused by the switch from DIV to PRE for code blocks. I've fixed this for Chromium and Firefox on Linux in revision 275043ee62 of the fixspacing branch. Can anyone check whether the problem is fixed for IE and Windows too? There might be some subtleties with newline differences. (I'll merge this branch into master if it fixes the problem well. Probably a bit overkill for this small issue, but I like experimenting with the new DVCS. :-) Status: Started As Alberto noticed in chat, this is likely caused by the switch from DIV to PRE for code blocks. I've fixed this for Chromium and Firefox on Linux in revision 275043ee62 of the fixspacing branch. Can anyone check whether the problem is fixed for IE and Windows too? There might be some subtleties with newline differences. (I'll merge this branch into master if it fixes the problem well. Probably a bit overkill for this small issue, but I like experimenting with the new DVCS. :-) Status: Started Jun 10, 2009 Revision 275043ee62 (Remove spacing between code blocks Remove the margin from a...) pushed by sander.dijkhuis - Remove spacing between code blocks Remove the margin from and add a newline to each code block. This is needed since the switch from DIV to PRE introduced whitespace between code blocks (issue 13). Remove spacing between code blocks Remove the margin from and add a newline to each code block. This is needed since the switch from DIV to PRE introduced whitespace between code blocks (issue 13). Jun 10, 2009 Revision bd983d4973 (Add Alberto to the list of contributors) pushed by sander.dijkhuis - Add Alberto to the list of contributors Add Alberto to the list of contributors Jun 09, 2009 2 new revisions pushed by sander.dijkhuis - Revision 1bcd5094a4:Add triangles before documented code sections Revision 60ed129d6d:Break the 50-50 layout and increase the code font size Revision 1bcd5094a4:Add triangles before documented code sections Revision 60ed129d6d:Break the 50-50 layout and increase the code font size Jun 09, 2009 26 new revisions pushed by sander.dijkhuis - Revision 5484627851:Initial directory structure. Revision ad3e440c15:Origination; files taken directly from the 'ubiquity' directory of the HG repository http://hg.toolness.com/ubiquity-firefox, rev 3829bcefa1de. Revision fb22acdc9a:Committed Sander Dijkhuis' patch for decoupling MDC and XULPlanet linking from docs.js. Sander's notes: Adding the menu items now happens in index.html, by using an API in the App namespace. This extra code in index.html could also be placed in a separate file like docs/mozilla_docs.js, so that other Mozilla projects can benefit from the documentation linking. Thanks for the patch, Sander! Revision fba2673a2b:Added Sander to list of contributors. Revision 5c1e09897c:Changed index.html to reflect Code Illuminated instead of Ubiquity; the TOC now points to CI code instead of Ubiquity code. Also added a scripts directory w/ jquery and wikicreole JS libraries. (Perhaps the directory should actually be called 'third-party', though.) Revision 072fe6bc64:Set HTML mime type for index.html. Revision 90c4b9495a:Set MIME type for docs.css. Revision 7f6ddd97e7:Changed font choice for Windows. Thanks to Alejandro Moreno for his comment: http://www.toolness.com/wp/?p=441#comment-1466 class="ot-revlogs-br-2"> Revision 2b7a11e45b:Added Creole documentation for some functions in docs.js. Revision 1714d7357f:Changed the name of the #docs/docs.js link on the overview page. (It still had a name from Ubiquity.) Revision 50b56dbf2d:Copied some CSS cleanups by Christian Sonne from the Ubiquity repository: http://hg.toolness.com/ubiquity-firefox/rev/d2a615ca5779 class="ot-revlogs-br-2"> Revision d30e2798c5:Copied the design update by Christian Sonne from the Ubiquity repository, with some small syntax changes: http://hg.toolness.com/ubiquity-firefox/rev/d2a615ca5779 class="ot-revlogs-br-2"> Revision 98c67e72e7:Replace \r\n by \n in Windows-newlined source code files. They caused processing bugs. Revision 5491f159c9:First fix for IE: text.charAt(0) instead of text[0]. Treating the string as an array is not part of the ECMAScript; it's a JavaScript feature. There are boxing (-moz-box-sizing), fonts and code justification issues, but something is displayed using IE. Revision 7ebb0824cd:Fixed issue #1 - Spaces between // and wiki tag. Trimmed the line sliced by "//". Revision be770e45ef:Merged changes from the Ubiquity repository: reverted to the first design, automatically determine column widths and paddings based on the font size. Revision 6c834f0357:Fixed issue #3 - With IE the code is one line. I added a "\r" when the text is code and added a ugly workaround in css for pre blocks created by {{{ ... }}} tags. Revision 0280680536:Fixed issue 5 - With IE "{{{" and "}}}" multiline block problem. IE requires CR-LF line endings to render preformatted blocks properly. Creole parser updated to 0.1.1 and added an option, forIE to the creole parser call: it seems Firefox is tolerant about endline in pre blocks. Revision 5526feb21e:Updated jQuery to 1.3.1 - production release. Moved script tags before body tag. Revision 9792030289:Fixed issue#6 : windows files "\n\r". Tested with CR, CR/LF and LF end line on IE7 and FF 3.0.6. Revision a0cd73d7b2:Updated jQuery to 1.3.2 - development release (in case of debugging needs). Revision 59e4d65d07:Remove lucidatypewriter from the monospace font list. It was a fallback font for non-Mac, non-Windows systems, but there it's often only available in a bitmap form that looks worse than the default monospace font. Revision 4016feda1f:Fixed issue #9 : Can't embed links or images in tables. wikicreole updated. Revision 74cfc04113:Added tests directory containing manual tests (no unit test). Revision d4ebea29c5:Added the double clicking event on the content: if you select a word double clicking on it, it will be yellow highlighted in the documentation and code section, illuminating all the occurences of that word. Revision 0e7f3c1053:Added syntax highlighting with google-code-prettify. The code section is contained in a "pre tag", prettified with the function prettyPrint(); in "prettify.css" stylesheet has been commented the "pre" tag styles. Revision 5484627851:Initial directory structure. Revision ad3e440c15:Origination; files taken directly from the 'ubiquity' directory of the HG repository http://hg.toolness.com/ubiquity-firefox, rev 3829bcefa1de. Revision fb22acdc9a:Committed Sander Dijkhuis' patch for decoupling MDC and XULPlanet linking from docs.js. Sander's notes: Adding the menu items now happens in index.html, by using an API in the App namespace. This extra code in index.html could also be placed in a separate file like docs/mozilla_docs.js, so that other Mozilla projects can benefit from the documentation linking. Thanks for the patch, Sander! Revision fba2673a2b:Added Sander to list of contributors. Revision 5c1e09897c:Changed index.html to reflect Code Illuminated instead of Ubiquity; the TOC now points to CI code instead of Ubiquity code. Also added a scripts directory w/ jquery and wikicreole JS libraries. (Perhaps the directory should actually be called 'third-party', though.) Revision 072fe6bc64:Set HTML mime type for index.html. Revision 90c4b9495a:Set MIME type for docs.css. Revision 7f6ddd97e7:Changed font choice for Windows. Thanks to Alejandro Moreno for his comment: http://www.toolness.com/wp/?p=441#comment-1466 class="ot-revlogs-br-2"> Revision 2b7a11e45b:Added Creole documentation for some functions in docs.js. Revision 1714d7357f:Changed the name of the #docs/docs.js link on the overview page. (It still had a name from Ubiquity.) Revision 50b56dbf2d:Copied some CSS cleanups by Christian Sonne from the Ubiquity repository: http://hg.toolness.com/ubiquity-firefox/rev/d2a615ca5779 class="ot-revlogs-br-2"> Revision d30e2798c5:Copied the design update by Christian Sonne from the Ubiquity repository, with some small syntax changes: http://hg.toolness.com/ubiquity-firefox/rev/d2a615ca5779 class="ot-revlogs-br-2"> Revision 98c67e72e7:Replace \r\n by \n in Windows-newlined source code files. They caused processing bugs. Revision 5491f159c9:First fix for IE: text.charAt(0) instead of text[0]. Treating the string as an array is not part of the ECMAScript; it's a JavaScript feature. There are boxing (-moz-box-sizing), fonts and code justification issues, but something is displayed using IE. Revision 7ebb0824cd:Fixed issue #1 - Spaces between // and wiki tag. Trimmed the line sliced by "//". Revision be770e45ef:Merged changes from the Ubiquity repository: reverted to the first design, automatically determine column widths and paddings based on the font size. Revision 6c834f0357:Fixed issue #3 - With IE the code is one line. I added a "\r" when the text is code and added a ugly workaround in css for pre blocks created by {{{ ... }}} tags. Revision 0280680536:Fixed issue 5 - With IE "{{{" and "}}}" multiline block problem. IE requires CR-LF line endings to render preformatted blocks properly. Creole parser updated to 0.1.1 and added an option, forIE to the creole parser call: it seems Firefox is tolerant about endline in pre blocks. Revision 5526feb21e:Updated jQuery to 1.3.1 - production release. Moved script tags before body tag. Revision 9792030289:Fixed issue#6 : windows files "\n\r". Tested with CR, CR/LF and LF end line on IE7 and FF 3.0.6. Revision a0cd73d7b2:Updated jQuery to 1.3.2 - development release (in case of debugging needs). Revision 59e4d65d07:Remove lucidatypewriter from the monospace font list. It was a fallback font for non-Mac, non-Windows systems, but there it's often only available in a bitmap form that looks worse than the default monospace font. Revision 4016feda1f:Fixed issue #9 : Can't embed links or images in tables. wikicreole updated. Revision 74cfc04113:Added tests directory containing manual tests (no unit test). Revision d4ebea29c5:Added the double clicking event on the content: if you select a word double clicking on it, it will be yellow highlighted in the documentation and code section, illuminating all the occurences of that word. Revision 0e7f3c1053:Added syntax highlighting with google-code-prettify. The code section is contained in a "pre tag", prettified with the function prettyPrint(); in "prettify.css" stylesheet has been commented the "pre" tag styles. Jun 09, 2009 issue 13 (Code blocks have incorrect spacing) reported by sander.dijkhuis - Since the r26 commit, which introduced prettify for syntax highlighting, code blocks are separated by whitespace. I've tested in Chromium 3.0.184.0 and Firefox 3.5pre (20090609). I haven't been able to find the cause yet, but I tried using Firebug and adding margin:0 to .code in docs.css. Since the r26 commit, which introduced prettify for syntax highlighting, code blocks are separated by whitespace. I've tested in Chromium 3.0.184.0 and Firefox 3.5pre (20090609). I haven't been able to find the cause yet, but I tried using Firebug and adding margin:0 to .code in docs.css. Jun 06, 2009 issue 12 (Click a method call to jump to its definition) reported by sander.dijkhuis - In a gnome-shell bug about CI, Owen Taylor writes: > Cross-references: A hard one given the nature of Javascript, but being > able to jump directly from where a method is called to the docs of that > method would be a huge win for a code browser. Possible idea that avoids > type inference: When someone clicks on a method name, show a menu of all > methods with that name in the project. Many method names will be unique. http://bugzilla.gnome.org/show_bug.cgi?id=574573#c1 Finding method definitions is described in Issue 11. The menu could be the quasimodal one, so we would use App.addMenuItem() on method call strings for which we found the definition. In a gnome-shell bug about CI, Owen Taylor writes: > Cross-references: A hard one given the nature of Javascript, but being > able to jump directly from where a method is called to the docs of that > method would be a huge win for a code browser. Possible idea that avoids > type inference: When someone clicks on a method name, show a menu of all > methods with that name in the project. Many method names will be unique. http://bugzilla.gnome.org/show_bug.cgi?id=574573#c1 Finding method definitions is described in Issue 11. The menu could be the quasimodal one, so we would use App.addMenuItem() on method call strings for which we found the definition. Jun 05, 2009 issue 11 (Automatically recognize method definitions (and other code s...) reported by sander.dijkhuis - In a gnome-shell bug about CI, Owen Taylor writes: > Having to add wiki-markup to mark each class and function is a bit > cumbersome. Having undocumented functions not show up at all could be > confusing. The code describes itself what the functions are, what the > classes are, it would be nice if the tool could pick that up. http://bugzilla.gnome.org/show_bug.cgi?id=574573#c1 Because JavaScript allows for multiple ways of defining functions, and you might not want to document inline functions or private methods, it seems hard to find a one-size-fits-all solution. So I think we at least need to allow for some manual per-project configuaration. There are some things CI could do automatically. For example, the following ways of defining a method seem to be often used: MyObject.prototype.myMethod = function myMethod(arg) { ... }; MyObject.prototype = { myMethod: function(arg) { ... } }; CI should recognize both constructions and add a "MyObject.myMethod(arg)" header. (I think the arguments should be included, but this may be debatable.) If such a header is already in the Creole comment, it should not be automatically duplicated of course. I think the main point of this would be to avoid confusion about why a new method isn't added to the docs yet, and to keep the CI pages structured even when the documentation isn't finished yet. In a gnome-shell bug about CI, Owen Taylor writes: > Having to add wiki-markup to mark each class and function is a bit > cumbersome. Having undocumented functions not show up at all could be > confusing. The code describes itself what the functions are, what the > classes are, it would be nice if the tool could pick that up. http://bugzilla.gnome.org/show_bug.cgi?id=574573#c1 Because JavaScript allows for multiple ways of defining functions, and you might not want to document inline functions or private methods, it seems hard to find a one-size-fits-all solution. So I think we at least need to allow for some manual per-project configuaration. There are some things CI could do automatically. For example, the following ways of defining a method seem to be often used: MyObject.prototype.myMethod = function myMethod(arg) { ... }; MyObject.prototype = { myMethod: function(arg) { ... } }; CI should recognize both constructions and add a "MyObject.myMethod(arg)" header. (I think the arguments should be included, but this may be debatable.) If such a header is already in the Creole comment, it should not be automatically duplicated of course. I think the main point of this would be to avoid confusion about why a new method isn't added to the docs yet, and to keep the CI pages structured even when the documentation isn't finished yet. Jun 05, 2009 r26 (Added syntax highlighting with google-code-prettify. The cod...) committed by albertosantini - Added syntax highlighting with google-code-prettify. The code section is contained in a "pre tag", prettified with the function prettyPrint(); in "prettify.css" stylesheet has been commented the "pre" tag styles. Added syntax highlighting with google-code-prettify. The code section is contained in a "pre tag", prettified with the function prettyPrint(); in "prettify.css" stylesheet has been commented the "pre" tag styles. Jun 05, 2009 issue 10 (The code font is hardly readable) reported by sander.dijkhuis - The font used in the second column is too small for the code to be comfortably readable. This isn't a problem when reading the docs for a quick overview of the code structure, but makes it hard to see what each line of code does. This may be a Linux-only problem, where the fallback monospace font is used. In most Linux distributions, this is Bitstream Vera Sans Mono (or the DejaVu fork, which has the same proportions). But, judging from the following screenshot, the situation is only a bit better on Mac: http://www.flickr.com/photos/azaraskin/3186397391/sizes/o/ For reference, I've attached a screenshot of the current look of CI, and one where the text is page is zoomed so that the code is readable, but with too large documentation fonts. I'm using Ubuntu with font hinting disabled, but other font settings still don't make the fonts much larger of course. This could be solved by breaking the nice 50-50 layout that's currently used, making the code column wider and the code text larger. Also, a font with a larger x-height like Monaco could be included with @font-face. For printers, the current 50-50 layout still seems like the best possible, so only changing the font might be enough to make the code more readable. The font used in the second column is too small for the code to be comfortably readable. This isn't a problem when reading the docs for a quick overview of the code structure, but makes it hard to see what each line of code does. This may be a Linux-only problem, where the fallback monospace font is used. In most Linux distributions, this is Bitstream Vera Sans Mono (or the DejaVu fork, which has the same proportions). But, judging from the following screenshot, the situation is only a bit better on Mac: http://www.flickr.com/photos/azaraskin/3186397391/sizes/o/ For reference, I've attached a screenshot of the current look of CI, and one where the text is page is zoomed so that the code is readable, but with too large documentation fonts. I'm using Ubuntu with font hinting disabled, but other font settings still don't make the fonts much larger of course. This could be solved by breaking the nice 50-50 layout that's currently used, making the code column wider and the code text larger. Also, a font with a larger x-height like Monaco could be included with @font-face. For printers, the current 50-50 layout still seems like the best possible, so only changing the font might be enough to make the code more readable. Apr 15, 2009 r25 (Added the double clicking event on the content: if you selec...) committed by albertosantini - Added the double clicking event on the content: if you select a word double clicking on it, it will be yellow highlighted in the documentation and code section, illuminating all the occurences of that word. Added the double clicking event on the content: if you select a word double clicking on it, it will be yellow highlighted in the documentation and code section, illuminating all the occurences of that word. Mar 22, 2009 r24 (Added tests directory containing manual tests (no unit test)...) committed by albertosantini - Added tests directory containing manual tests (no unit test). Added tests directory containing manual tests (no unit test). Mar 22, 2009 issue 9 (Can't embed links or images in tables) changed by albertosantini - Fixed in release 23, updating wikicreole parser. Thanks Ivan. Tested with the following text: // {{{ Test image in table }}} // \|= Header 1 \|= Header 2 \| // \| [[http://www.ibm.com\|Big Corp]] \| some text in col 2 \| // \| {{http://www.wikicreole.org/attach/LeftMenu/viki.png\|Creole 1.0}} \| more text in col 2 \| Status: Fixed Owner: albertosantini Fixed in release 23, updating wikicreole parser. Thanks Ivan. Tested with the following text: // {{{ Test image in table }}} // \|= Header 1 \|= Header 2 \| // \| [[http://www.ibm.com\|Big Corp]] \| some text in col 2 \| // \| {{http://www.wikicreole.org/attach/LeftMenu/viki.png\|Creole 1.0}} \| more text in col 2 \| Status: Fixed Owner: albertosantini Mar 22, 2009 r23 (Fixed issue #9: Can't embed links or images in tables. wikic...) committed by albertosantini - Fixed issue #9 : Can't embed links or images in tables. wikicreole updated. Fixed issue #9 : Can't embed links or images in tables. wikicreole updated. Mar 21, 2009 issue 9 (Can't embed links or images in tables) commented on by ifomichev - Fixed in 0.2.0 There is a new option: 'strict', which is false by default. A non-strict parser allows images in tables and images with no alternative text. Fixed in 0.2.0 There is a new option: 'strict', which is false by default. A non-strict parser allows images in tables and images with no alternative text. Mar 09, 2009 issue 9 (Can't embed links or images in tables) commented on by ifomichev - WikiCreole 1.0 doesn't explicitly specify you can embed images into tables, see http://wikicreole.org/wiki/Creole1.0#section-Creole1.0-Tables However, I think it is not a problem to make it possible. Let me see what I can do. WikiCreole 1.0 doesn't explicitly specify you can embed images into tables, see http://wikicreole.org/wiki/Creole1.0#section-Creole1.0-Tables However, I think it is not a problem to make it possible. Let me see what I can do. Mar 04, 2009 issue 9 (Can't embed links or images in tables) reported by emerge.update.world - What steps will reproduce the problem? 1. Try to render the following mark-up \|= Header 1 \|= Header 2 \| \| [[http://www.ibm.com\|Big Corp]] \| some text in col 2 \| \| {{http://www.wikicreole.org/attach/LeftMenu/viki.png\|Creole 1.0}} \| more text in col 2 \| You can use the textbox at http://www.ivan.fomichev.name/2008/04/javascript-creole-10-wiki-markup-parser.html to test. What is the expected output? What do you see instead? The link should be rendered as a <a> element and the image as a <img> element. What version of the product are you using? On what operating system? code 1.0 rev 12, tested in firefox 3.0.6 and IE 7.0 Please provide any additional information below. What steps will reproduce the problem? 1. Try to render the following mark-up \|= Header 1 \|= Header 2 \| \| [[http://www.ibm.com\|Big Corp]] \| some text in col 2 \| \| {{http://www.wikicreole.org/attach/LeftMenu/viki.png\|Creole 1.0}} \| more text in col 2 \| You can use the textbox at http://www.ivan.fomichev.name/2008/04/javascript-creole-10-wiki-markup-parser.html to test. What is the expected output? What do you see instead? The link should be rendered as a <a> element and the image as a <img> element. What version of the product are you using? On what operating system? code 1.0 rev 12, tested in firefox 3.0.6 and IE 7.0 Please provide any additional information below. Feb 25, 2009 r22 (Remove lucidatypewriter from the monospace font list. It wa...) committed by sander.dijkhuis - Remove lucidatypewriter from the monospace font list. It was a fallback font for non-Mac, non-Windows systems, but there it's often only available in a bitmap form that looks worse than the default monospace font. Remove lucidatypewriter from the monospace font list. It was a fallback font for non-Mac, non-Windows systems, but there it's often only available in a bitmap form that looks worse than the default monospace font. Feb 24, 2009 r21 (Updated jQuery to 1.3.2 - development release (in case of de...) committed by albertosantini - Updated jQuery to 1.3.2 - development release (in case of debugging needs). Updated jQuery to 1.3.2 - development release (in case of debugging needs). Feb 20, 2009 issue 8 (App.processors only once ?) commented on by Denis.Bo...@imag.fr - But maybe there is a better solution? (I've not seen why the page was not "get" the second time, and App.processors not processed ; but it could be a reasonible choice, from some point of view) So, how can you force the processing of App.processors when a 'page' is shown (even the second time)? But maybe there is a better solution? (I've not seen why the page was not "get" the second time, and App.processors not processed ; but it could be a reasonible choice, from some point of view) So, how can you force the processing of App.processors when a 'page' is shown (even the second time)? Feb 19, 2009 issue 8 (App.processors only once ?) reported by Denis.Bo...@imag.fr - It seems that the App.processors are processed only the first time. I've tried to add some 'no-cache', it didn't matter: the file is "Get" only once, and App.processors processed only once too. (a REST issue ?) As it was important for internal link (see prev. issue), I've add some changing date in the url, and the file is "Get" every time, and App.processors processed each time. the code: (in the App.processors) changed the href (add a date) on internal link (when necessary), so that internal link are really "Get". function (docs) { $(docs).find('a').each(function (i) { var d = this.href.indexOf('#'); var e = this.href.lastIndexOf('#'); if ( (d > 1) && (d!=e) ) { var txt = this.href.slice(0,e); var tyt = this.href.slice(e,this.href.length); var now = new Date(); this.href = txt + '?date=' + now.getTime() +'&target=' + tyt; } }) } It seems that the App.processors are processed only the first time. I've tried to add some 'no-cache', it didn't matter: the file is "Get" only once, and App.processors processed only once too. (a REST issue ?) As it was important for internal link (see prev. issue), I've add some changing date in the url, and the file is "Get" every time, and App.processors processed each time. the code: (in the App.processors) changed the href (add a date) on internal link (when necessary), so that internal link are really "Get". function (docs) { $(docs).find('a').each(function (i) { var d = this.href.indexOf('#'); var e = this.href.lastIndexOf('#'); if ( (d > 1) && (d!=e) ) { var txt = this.href.slice(0,e); var tyt = this.href.slice(e,this.href.length); var now = new Date(); this.href = txt + '?date=' + now.getTime() +'&target=' + tyt; } }) } Feb 19, 2009 issue 7 (Adding internal link) commented on by Denis.Bo...@imag.fr - about focus, a very small improvment (I've tried to focus few lines after the target): $(docs).find('h1:contains("'+g+'")')[0].innerHTML= n+'<br /><br /><br /><input type="text" size="1" style="border:0px" id="focusTarget">focusTarget</input>'; $('#focusTarget').focus(); $(docs).find('h1:contains("'+g+'")')[0].innerHTML=n; about focus, a very small improvment (I've tried to focus few lines after the target): $(docs).find('h1:contains("'+g+'")')[0].innerHTML= n+'<br /><br /><br /><input type="text" size="1" style="border:0px" id="focusTarget">focusTarget</input>'; $('#focusTarget').focus(); $(docs).find('h1:contains("'+g+'")')[0].innerHTML=n; Feb 18, 2009 issue 7 (Adding internal link) commented on by Denis.Bo...@imag.fr - bug "<a> do not focus" solved Tested on ff3 and chrome. Working example: http://www.noe-kaleidoscope.org/public/people/DenisB/EDBA/Tables/docsTables.html follows normal link: xMail.js then the new special internal link: docsTables.html#login.js#IdUser Solution: App.processors = [ function (docs) { if (document.location.hash) { var d = document.location.hash.slice(1,document.location.hash.length).indexOf('#'); if ( d > 1 ) { var g = document.location.hash.slice(2+d,document.location.hash.length); if ($(docs).find('h1:contains("'+g+'")').length) { var n = $(docs).find('h1:contains("'+g+'")')[0].innerHTML; $(docs).find('h1:contains("'+g+'")')[0].innerHTML= n+'<input type="text" size="1" style="border:0px" id="focusTarget">focusTarget</input>'; $('#focusTarget').focus(); $(docs).find('h1:contains("'+g+'")')[0].innerHTML=n; } else if ($(docs).find('h2:contains("'+g+'")').length) { var n = $(docs).find('h2:contains("'+g+'")')[0].innerHTML; $(docs).find('h2:contains("'+g+'")')[0].innerHTML= n+'<input type="text" size="1" style="border:0px" id="focusTarget">focusTarget</input>'; $('#focusTarget').focus(); $(docs).find('h2:contains("'+g+'")')[0].innerHTML=n; } } } } ]; bug "<a> do not focus" solved Tested on ff3 and chrome. Working example: http://www.noe-kaleidoscope.org/public/people/DenisB/EDBA/Tables/docsTables.html follows normal link: xMail.js then the new special internal link: docsTables.html#login.js#IdUser Solution: App.processors = [ function (docs) { if (document.location.hash) { var d = document.location.hash.slice(1,document.location.hash.length).indexOf('#'); if ( d > 1 ) { var g = document.location.hash.slice(2+d,document.location.hash.length); if ($(docs).find('h1:contains("'+g+'")').length) { var n = $(docs).find('h1:contains("'+g+'")')[0].innerHTML; $(docs).find('h1:contains("'+g+'")')[0].innerHTML= n+'<input type="text" size="1" style="border:0px" id="focusTarget">focusTarget</input>'; $('#focusTarget').focus(); $(docs).find('h1:contains("'+g+'")')[0].innerHTML=n; } else if ($(docs).find('h2:contains("'+g+'")').length) { var n = $(docs).find('h2:contains("'+g+'")')[0].innerHTML; $(docs).find('h2:contains("'+g+'")')[0].innerHTML= n+'<input type="text" size="1" style="border:0px" id="focusTarget">focusTarget</input>'; $('#focusTarget').focus(); $(docs).find('h2:contains("'+g+'")')[0].innerHTML=n; } } } } ]; Feb 18, 2009 issue 7 (Adding internal link) commented on by Denis.Bo...@imag.fr - >[[#mypage.js]] or [[#mypage.js\|mypage]] are rendered correctly and, >if you follow the link, the target page is rendered as well. yes, it's ok. >About adding an internal link I read the section Inner Page Anchors: > >http://www.wikicreole.org/wiki/Talk.Links > >>My suggestion is the following >> >>[[#1]] -> <a name='1' /> >> >>as stated in that talk and >> >>[[#1\|text]] -> <a name='1' href='#1'>text</a> >> I had, some more comment from the page: >>>I'd prefer a clearer way to disambiguate anchors and links, >>>so that links don't need text; e.g. [[@Chater1]] for anchor and >>>[[#Chapter1]] or [[#Chapter1\|Chapter 1]] for link. >> (even more true, here, because # have also some meaning in docs ...) >Just adding to [[...]] tag the name attribute, it would be an >automatic anchor for another link. > >I think this changes should be done in wiki parser, >but I will give a look in the code later. ok. about internal : I mean internal, from the point of view of the wiki (idem for the comment from wiki creole), with Code Illuminated, it means internal to some file in the documentation (but which file? it is to be said somewhere), not just internal to the current file. The wiki, it is the set of all files of the documentation. >[[#mypage.js]] or [[#mypage.js\|mypage]] are rendered correctly and, >if you follow the link, the target page is rendered as well. yes, it's ok. >About adding an internal link I read the section Inner Page Anchors: > >http://www.wikicreole.org/wiki/Talk.Links > >>My suggestion is the following >> >>[[#1]] -> <a name='1' /> >> >>as stated in that talk and >> >>[[#1\|text]] -> <a name='1' href='#1'>text</a> >> I had, some more comment from the page: >>>I'd prefer a clearer way to disambiguate anchors and links, >>>so that links don't need text; e.g. [[@Chater1]] for anchor and >>>[[#Chapter1]] or [[#Chapter1\|Chapter 1]] for link. >> (even more true, here, because # have also some meaning in docs ...) >Just adding to [[...]] tag the name attribute, it would be an >automatic anchor for another link. > >I think this changes should be done in wiki parser, >but I will give a look in the code later. ok. about internal : I mean internal, from the point of view of the wiki (idem for the comment from wiki creole), with Code Illuminated, it means internal to some file in the documentation (but which file? it is to be said somewhere), not just internal to the current file. The wiki, it is the set of all files of the documentation. Feb 18, 2009 issue 7 (Adding internal link) changed by albertosantini - [[#mypage.js]] or [[#mypage.js\|mypage]] are rendered correctly and, if you follow the link, the target page is rendered as well. About adding an internal link I read the section Inner Page Anchors: http://www.wikicreole.org/wiki/Talk.Links My suggestion is the following [[#1]] -> <a name='1' /> as stated in that talk and [[#1\|text]] -> <a name='1' href='#1'>text</a> Just adding to [[...]] tag the name attribute, it would be an automatic anchor for another link. I think this changes should be done in wiki parser, but I will give a look in the code later. Owner: albertosantini Labels: Type-Enhancement −Type-Defect [[#mypage.js]] or [[#mypage.js\|mypage]] are rendered correctly and, if you follow the link, the target page is rendered as well. About adding an internal link I read the section Inner Page Anchors: http://www.wikicreole.org/wiki/Talk.Links My suggestion is the following [[#1]] -> <a name='1' /> as stated in that talk and [[#1\|text]] -> <a name='1' href='#1'>text</a> Just adding to [[...]] tag the name attribute, it would be an automatic anchor for another link. I think this changes should be done in wiki parser, but I will give a look in the code later. Owner: albertosantini Labels: Type-Enhancement −Type-Defect Feb 18, 2009 issue 7 (Adding internal link) commented on by Denis.Bo...@imag.fr - It worked in ff 2.XXX but not in ff 3.XXX (in ff 3.XX the <a> do not focus), I'll have to change a bit (maybe add a small <input> or something else which do focus) It worked in ff 2.XXX but not in ff 3.XXX (in ff 3.XX the <a> do not focus), I'll have to change a bit (maybe add a small <input> or something else which do focus) Feb 16, 2009 issue 7 (Adding internal link) commented on by Denis.Bo...@imag.fr - hum ... http://www.noe-kaleidoscope.org/public/people/DenisB/EDBA/Tables/docsTables.html is better (sorry) hum ... http://www.noe-kaleidoscope.org/public/people/DenisB/EDBA/Tables/docsTables.html is better (sorry) Feb 16, 2009 issue 7 (Adding internal link) reported by Denis.Bo...@imag.fr - At least one thing is missing in "Code Illuminated" to improve use, to be closer to wiki or to reduce the gap with "Literate Programming": an easy internal linking facility to target one part of the commented JS code. Something like [[wikiPage]]. As far as wikiCreole is concerned, redactors should be able to write [[bipbip]], and readers could follow the link which should lead them to some entry "bipbip". But in "Code Illuminated", wikiCreole is mostly used for formating and not for internal linking. If you write[[bipbip]] in a js file, there would be a link in the formated text, ok, and if you follow that link, it would lead you to a file "bipbip" (if it exists) ((maybe [[bipbip.js]] would have been better, for that purpose)) but unfortunaltly, it would not format it! And you do not have targetet one part of the file. The main problem, from my point of view, is that files does not corespond to the notion of entry in a wiki or chunk of code in "Literate Programming". What I would like to have, when I follow a link [[bipbip]], is the part of a file (A file?) related to "bipbip". So, first remark, which file? In fact, "Code Illuminated" works with a collection of sources/files, so entry "bipbip" should be associated to a file. Why not write [[theRightFile.js#bipbip]]? I've chosen the metacharacter "#" as a reference to html anchor. It could be changed. Second, I would like to have a formatted text, so we have to pass through the index.html (or any html file you used as the basis of your documentation), if we follow the way "Code Illuminated" works we should write [[index.html#theRightFile.js#bipbip]] Then, finally, "Code Illuminated" or html should understand what we have written... Here a function which try to find 'bipbip' (or anything you want) in the headers (h1 or h2) of a file, and focus on it. I've put it in the list of user-post-processed-functions: App.processors = [ function (docs) { if (document.location.hash) { var d = document.location.hash.slice(1,document.location.hash.length).indexOf('#'); if ( d > 1 ) { var g = document.location.hash.slice(2+d,document.location.hash.length); //the target find in the url if ($(docs).find('h1:contains("'+g+'")').length) { var n = $(docs).find('h1:contains("'+g+'")')[0].innerHTML //the target find in the file $(docs).find('h1:contains("' + g + '")')[0].innerHTML = '<a id="' + n + '" name="' + n + '">' + n + '</a>'; $('#' + n).focus(); } else if ($(docs).find('h2:contains("'+g+'")').length) { var n = $(docs).find('h2:contains("'+g+'")')[0].innerHTML; $(docs).find('h2:contains("' + g + '")')[0].innerHTML = '<a id="' + n + '" name="' + n + '">' + n + '</a>'; $('#' + n).focus(); } } } } ]; There is a working example there: http://www.noe-kaleidoscope.org/public/people/DenisB/EDBA/docsTables.html follows normal link: xMail.js then the new special internal link: docsTables.html#login.js#IdUser Possible improvment : * change the way to indicate the target #, @, ->, ?, (), ...? (personnaly, I would prefer docsTables.html?login.js#IdUser) * automatically insert the name of the base file "index.html" + "#" (but it should be done during the parsing phase) * the target "bipbip" is find via $('h1:contains("bipbip")') (or else $('h2:contains("bipbip")')) It could be improved (a css selector? xpath? or ... but this is not the philosophy of wiki) and then, why not add it to "the core code of Code Illuminated" At least one thing is missing in "Code Illuminated" to improve use, to be closer to wiki or to reduce the gap with "Literate Programming": an easy internal linking facility to target one part of the commented JS code. Something like [[wikiPage]]. As far as wikiCreole is concerned, redactors should be able to write [[bipbip]], and readers could follow the link which should lead them to some entry "bipbip". But in "Code Illuminated", wikiCreole is mostly used for formating and not for internal linking. If you write[[bipbip]] in a js file, there would be a link in the formated text, ok, and if you follow that link, it would lead you to a file "bipbip" (if it exists) ((maybe [[bipbip.js]] would have been better, for that purpose)) but unfortunaltly, it would not format it! And you do not have targetet one part of the file. The main problem, from my point of view, is that files does not corespond to the notion of entry in a wiki or chunk of code in "Literate Programming". What I would like to have, when I follow a link [[bipbip]], is the part of a file (A file?) related to "bipbip". So, first remark, which file? In fact, "Code Illuminated" works with a collection of sources/files, so entry "bipbip" should be associated to a file. Why not write [[theRightFile.js#bipbip]]? I've chosen the metacharacter "#" as a reference to html anchor. It could be changed. Second, I would like to have a formatted text, so we have to pass through the index.html (or any html file you used as the basis of your documentation), if we follow the way "Code Illuminated" works we should write [[index.html#theRightFile.js#bipbip]] Then, finally, "Code Illuminated" or html should understand what we have written... Here a function which try to find 'bipbip' (or anything you want) in the headers (h1 or h2) of a file, and focus on it. I've put it in the list of user-post-processed-functions: App.processors = [ function (docs) { if (document.location.hash) { var d = document.location.hash.slice(1,document.location.hash.length).indexOf('#'); if ( d > 1 ) { var g = document.location.hash.slice(2+d,document.location.hash.length); //the target find in the url if ($(docs).find('h1:contains("'+g+'")').length) { var n = $(docs).find('h1:contains("'+g+'")')[0].innerHTML //the target find in the file $(docs).find('h1:contains("' + g + '")')[0].innerHTML = '<a id="' + n + '" name="' + n + '">' + n + '</a>'; $('#' + n).focus(); } else if ($(docs).find('h2:contains("'+g+'")').length) { var n = $(docs).find('h2:contains("'+g+'")')[0].innerHTML; $(docs).find('h2:contains("' + g + '")')[0].innerHTML = '<a id="' + n + '" name="' + n + '">' + n + '</a>'; $('#' + n).focus(); } } } } ]; There is a working example there: http://www.noe-kaleidoscope.org/public/people/DenisB/EDBA/docsTables.html follows normal link: xMail.js then the new special internal link: docsTables.html#login.js#IdUser Possible improvment : * change the way to indicate the target #, @, ->, ?, (), ...? (personnaly, I would prefer docsTables.html?login.js#IdUser) * automatically insert the name of the base file "index.html" + "#" (but it should be done during the parsing phase) * the target "bipbip" is find via $('h1:contains("bipbip")') (or else $('h2:contains("bipbip")')) It could be improved (a css selector? xpath? or ... but this is not the philosophy of wiki) and then, why not add it to "the core code of Code Illuminated" Feb 13, 2009 issue 6 (windows files "\n\r") Owner changed by albertosantini - Owner: albertosantini Owner: albertosantini Feb 13, 2009 issue 6 (windows files "\n\r") Status changed by albertosantini - Fixed by revision 20. Thanks to Denis Bouhineau for the patch. Tested with CR, CR/LF and LF line end chars on IE7 and FF 3.0. Status: Fixed Fixed by revision 20. Thanks to Denis Bouhineau for the patch. Tested with CR, CR/LF and LF line end chars on IE7 and FF 3.0. Status: Fixed Feb 13, 2009 r20 (Fixed issue#6: windows files "\n\r". Tested with CR, CR/LF a...) committed by albertosantini - Fixed issue#6 : windows files "\n\r". Tested with CR, CR/LF and LF end line on IE7 and FF 3.0.6. Fixed issue#6 : windows files "\n\r". Tested with CR, CR/LF and LF end line on IE7 and FF 3.0.6. Feb 13, 2009 issue 6 (windows files "\n\r") commented on by Denis.Bo...@imag.fr - for windows files + mac files (but I do not have mac-os file, so ...) the change could be : App.processCode = function processCode(code, div) { var lines = code.replace(/\r\n/g,'\n').replace(/\r/g,'\n').split('\n'); ... (but I do not have mac-os file, so think twice, test it ...) for windows files + mac files (but I do not have mac-os file, so ...) the change could be : App.processCode = function processCode(code, div) { var lines = code.replace(/\r\n/g,'\n').replace(/\r/g,'\n').split('\n'); ... (but I do not have mac-os file, so think twice, test it ...) Feb 13, 2009 issue 6 (windows files "\n\r") commented on by Denis.Bo...@imag.fr - a small change (in docs.js) may be enough : App.processCode = function processCode(code, div) { var lines = code.replace(/\r\n/g,'\n').split('\n'); ... a small change (in docs.js) may be enough : App.processCode = function processCode(code, div) { var lines = code.replace(/\r\n/g,'\n').split('\n'); ... Feb 13, 2009 issue 6 (windows files "\n\r") reported by Denis.Bo...@imag.fr - It seems that "\r" of windows files are not parsed correctly. Maybe, a pre-process of the entry (removing of "\r") would be usefull. (but think twice : for mac-os, I'm not sure, is it "\r", "\r\n" or "\n" ?, if it is "\r", it would be nice not to remove "\r" but to replace "\r" with "\n") other solution (?) : introduce "\r" in the regex used by the parser. Best regards. (apart : very nice) It seems that "\r" of windows files are not parsed correctly. Maybe, a pre-process of the entry (removing of "\r") would be usefull. (but think twice : for mac-os, I'm not sure, is it "\r", "\r\n" or "\n" ?, if it is "\r", it would be nice not to remove "\r" but to replace "\r" with "\n") other solution (?) : introduce "\r" in the regex used by the parser. Best regards. (apart : very nice) Feb 05, 2009 r19 (Updated jQuery to 1.3.1 - production release. Moved script ...) committed by albertosantini - Updated jQuery to 1.3.1 - production release. Moved script tags before body tag. Updated jQuery to 1.3.1 - production release. Moved script tags before body tag. Feb 04, 2009 issue 5 (With IE "{{{" and "}}}" multiline block problem) Status changed by albertosantini - Awesome. Ivan, thanks for your support. Fixed in revision 18. Status: Fixed Awesome. Ivan, thanks for your support. Fixed in revision 18. Status: Fixed Feb 04, 2009 r18 (Fixed issue 5 - With IE "{{{" and "}}}" multiline block prob...) committed by albertosantini - Fixed issue 5 - With IE "{{{" and "}}}" multiline block problem. IE requires CR-LF line endings to render preformatted blocks properly. Creole parser updated to 0.1.1 and added an option, forIE to the creole parser call: it seems Firefox is tolerant about endline in pre blocks. Fixed issue 5 - With IE "{{{" and "}}}" multiline block problem. IE requires CR-LF line endings to render preformatted blocks properly. Creole parser updated to 0.1.1 and added an option, forIE to the creole parser call: it seems Firefox is tolerant about endline in pre blocks.

issue 7 (Adding internal link) reported by Denis.Bo...@imag.fr - At least one thing is missing in "Code Illuminated" to improve use, to be closer to wiki or to reduce the gap with "Literate Programming": an easy internal linking facility to target one part of the commented JS code. Something like [[wikiPage]]. As far as wikiCreole is concerned, redactors should be able to write [[bipbip]], and readers could follow the link which should lead them to some entry "bipbip". But in "Code Illuminated", wikiCreole is mostly used for formating and not for internal linking. If you write[[bipbip]] in a js file, there would be a link in the formated text, ok, and if you follow that link, it would lead you to a file "bipbip" (if it exists) ((maybe [[bipbip.js]] would have been better, for that purpose)) but unfortunaltly, it would not format it! And you do not have targetet one part of the file. The main problem, from my point of view, is that files does not corespond to the notion of entry in a wiki or chunk of code in "Literate Programming". What I would like to have, when I follow a link [[bipbip]], is the part of a file (A file?) related to "bipbip". So, first remark, which file? In fact, "Code Illuminated" works with a collection of sources/files, so entry "bipbip" should be associated to a file. Why not write [[theRightFile.js#bipbip]]? I've chosen the metacharacter "#" as a reference to html anchor. It could be changed. Second, I would like to have a formatted text, so we have to pass through the index.html (or any html file you used as the basis of your documentation), if we follow the way "Code Illuminated" works we should write [[index.html#theRightFile.js#bipbip]] Then, finally, "Code Illuminated" or html should understand what we have written... Here a function which try to find 'bipbip' (or anything you want) in the headers (h1 or h2) of a file, and focus on it. I've put it in the list of user-post-processed-functions: App.processors = [ function (docs) { if (document.location.hash) { var d = document.location.hash.slice(1,document.location.hash.length).indexOf('#'); if ( d > 1 ) { var g = document.location.hash.slice(2+d,document.location.hash.length); //the target find in the url if ($(docs).find('h1:contains("'+g+'")').length) { var n = $(docs).find('h1:contains("'+g+'")')[0].innerHTML //the target find in the file $(docs).find('h1:contains("' + g + '")')[0].innerHTML = '<a id="' + n + '" name="' + n + '">' + n + '</a>'; $('#' + n).focus(); } else if ($(docs).find('h2:contains("'+g+'")').length) { var n = $(docs).find('h2:contains("'+g+'")')[0].innerHTML; $(docs).find('h2:contains("' + g + '")')[0].innerHTML = '<a id="' + n + '" name="' + n + '">' + n + '</a>'; $('#' + n).focus(); } } } } ]; There is a working example there: http://www.noe-kaleidoscope.org/public/people/DenisB/EDBA/docsTables.html follows normal link: xMail.js then the new special internal link: docsTables.html#login.js#IdUser Possible improvment : * change the way to indicate the target #, @, ->, ?, (), ...? (personnaly, I would prefer docsTables.html?login.js#IdUser) * automatically insert the name of the base file "index.html" + "#" (but it should be done during the parsing phase) * the target "bipbip" is find via $('h1:contains("bipbip")') (or else $('h2:contains("bipbip")')) It could be improved (a css selector? xpath? or ... but this is not the philosophy of wiki) and then, why not add it to "the core code of Code Illuminated"

At least one thing is missing in "Code Illuminated" to improve use, to be closer to wiki or to reduce the gap with "Literate Programming": an easy internal linking facility to target one part of the commented JS code. Something like [[wikiPage]]. As far as wikiCreole is concerned, redactors should be able to write [[bipbip]], and readers could follow the link which should lead them to some entry "bipbip". But in "Code Illuminated", wikiCreole is mostly used for formating and not for internal linking. If you write[[bipbip]] in a js file, there would be a link in the formated text, ok, and if you follow that link, it would lead you to a file "bipbip" (if it exists) ((maybe [[bipbip.js]] would have been better, for that purpose)) but unfortunaltly, it would not format it! And you do not have targetet one part of the file. The main problem, from my point of view, is that files does not corespond to the notion of entry in a wiki or chunk of code in "Literate Programming". What I would like to have, when I follow a link [[bipbip]], is the part of a file (A file?) related to "bipbip". So, first remark, which file? In fact, "Code Illuminated" works with a collection of sources/files, so entry "bipbip" should be associated to a file. Why not write [[theRightFile.js#bipbip]]? I've chosen the metacharacter "#" as a reference to html anchor. It could be changed. Second, I would like to have a formatted text, so we have to pass through the index.html (or any html file you used as the basis of your documentation), if we follow the way "Code Illuminated" works we should write [[index.html#theRightFile.js#bipbip]] Then, finally, "Code Illuminated" or html should understand what we have written... Here a function which try to find 'bipbip' (or anything you want) in the headers (h1 or h2) of a file, and focus on it. I've put it in the list of user-post-processed-functions: App.processors = [ function (docs) { if (document.location.hash) { var d = document.location.hash.slice(1,document.location.hash.length).indexOf('#'); if ( d > 1 ) { var g = document.location.hash.slice(2+d,document.location.hash.length); //the target find in the url if ($(docs).find('h1:contains("'+g+'")').length) { var n = $(docs).find('h1:contains("'+g+'")')[0].innerHTML //the target find in the file $(docs).find('h1:contains("' + g + '")')[0].innerHTML = '<a id="' + n + '" name="' + n + '">' + n + '</a>'; $('#' + n).focus(); } else if ($(docs).find('h2:contains("'+g+'")').length) { var n = $(docs).find('h2:contains("'+g+'")')[0].innerHTML; $(docs).find('h2:contains("' + g + '")')[0].innerHTML = '<a id="' + n + '" name="' + n + '">' + n + '</a>'; $('#' + n).focus(); } } } } ]; There is a working example there: http://www.noe-kaleidoscope.org/public/people/DenisB/EDBA/docsTables.html follows normal link: xMail.js then the new special internal link: docsTables.html#login.js#IdUser Possible improvment : * change the way to indicate the target #, @, ->, ?, (), ...? (personnaly, I would prefer docsTables.html?login.js#IdUser) * automatically insert the name of the base file "index.html" + "#" (but it should be done during the parsing phase) * the target "bipbip" is find via $('h1:contains("bipbip")') (or else $('h2:contains("bipbip")')) It could be improved (a css selector? xpath? or ... but this is not the philosophy of wiki) and then, why not add it to "the core code of Code Illuminated"

Earlier this year