Item11254: Replace chili with a generic highlighter module

Priority: Enhancement
Current State: Closed
Released In: n/a
Target Release: n/a
Applies To: Extension
Component: JQueryPlugin
Branches: Release01x01 trunk
Reported By: PaulHarvey
Waiting For:
Last Change By: MichaelDaum
So, in Item11051, I:
  • Determined I couldn't fix Chili.
  • Decided it was a dead project (last update: 2008).
  • Made a TML syntax for GNU source-hilite, which works with shjs (used in snippet), but shjs is nearly as dead as chili.
  • Looked at google's code-prettify, but it's kinda lame and undocumented.
  • Decided ACE is awesome, but needs IE9+, and is relatively immature and undocumented.
  • Settled on codemirror...

So this task will be to make two new JQueryPlugins prettycode and codemirror, the former of which is an alias for the latter. Then at a later date if ACE is a better option, we can seamlessly move to that.

-- PaulHarvey - 15 Nov 2011

Wait a moment. Here's the snippet from Item11051 where I already commented on how to proceed:

Things to do:

  • direct use of chili (not via prettycode) should be deprecated immediately and switched off in Config.spec
  • add a config variable to chose the backend: chili, google code-prettifier, maybe later codemirror or ace as well
  • default to google code-prettifier backend
  • the new prettifier interacts the same way with topics as chili does by using verbatim blocks and their class attribute to select the syntax mode
  • syntax modes may have different names on the various backends, so we need a way to map them onto the same name users can chose from ... starting with the chili recpipe names that we have now extending the set of modes from there
  • JQREQUIRE{chili} should become an alias to JQREQUIRE{prettycode} (or JQREQUIRE{hilite} ... this is just naming that beast)

So I do not agree to make separate modules prettycode and codemirror. Instead, we need a single one with a generic name, say a hilite module, that is configurable in using one of the backends available.

Just for docu purposes so that we don't have to search working on this: Paul created TML rules for a new highlighter already at

-- MichaelDaum - 16 Nov 2011

hilite is fine, I just have trouble typing it (I keep typing highlight smile

I'm thinking of NatEditPlugin, and perhaps even the default raw editor, which will want to use codemirror or ace regardless of the backend selected for hilite.

-- PaulHarvey - 16 Nov 2011

And highlite is even worse to remember. Why not highlight?

-- ArthurClemens - 27 Dec 2011

I had to enable chili again to be able to upgrade to 1.1.4

As I work in a place full of software developers, they have already started to use the chili plugin all over the place. Instead we got error messages all over the place and no syntax highlight. So I have reenabled it.

We cannot just deprecate things like that! We have to be able to trust that TML and the shipping plugins work consistantly over releases. JQuery is no exception. We cannot add JQuery plugins and remove them like it was the wild west.

If we replace chili - we'd better make sure to continue having an alias called chili that just calls the new thing.

It also means that we have to take care to consider carefully before adding new things to JQuery. Right now it happens uncontrolled without any evaluation if the plugin added is stable and likely to be supported for many years.

-- KennethLavrsen - 04 Jan 2012

I have to agree with Kenneth on this. I got a large number of emails from users who asked what had happened to their code snippets.. SQL and BASH.. I had to re-enable it as well. Looking forward to the new solution however..

-- PadraigLennon - 04 Jan 2012

I'm a bit confused - if you just upgraded to 1.1.4, you would still have Chili - except you'd also get the following warning in configure
Chili highlighter plugin is known to corrupt displayed text on Firefox 7 and Safari Rev. 6-17-2011.
It's up to you whether or not to turn it off, depending upon knowledge of your user community. New installs end up with Chili disabled by default, which avoids corruption issues for the new user. Otherwise they will be cut/pasting examples that are broken due to hidden code in the examples.

I wouldn't call this exactly deprecated. It wasn't "just removed like the wild west". There should have been no changes after an upgrade following the upgrade instructions, unless someone read the warning and decided to disable the plugin. If your user community had a large number of ff7 or safari users, you would be on the other side, with lots of complaints about corrupted code examples ... like we saw popping up in the irc channel. New users were cutting and pasting broken code. JQuery unfortunately has been nowhere as stable as desired. The TextBoxList and Automplete issues are more severe than this one. Chili was a browser bug.

I'd actually even be more concerned if you are using chili highlighted code as cut/paste examples. I could imagine the results if a cut/paste of a bash script rendered "rm -rf /usr/local/blah.*" as "rm -rf *" It's a potentially critical data corruption issue caused by a browser bug outside of our control. Being somewhat conservative in how we handle possible corruption is preferable to just ignoring the issue as 'not our problem'.

-- GeorgeClark - 05 Jan 2012

Came across this alternative:

-- MichaelDaum - 01 Mar 2012

Chilli is not perfect but okay. There's no direct pressure to replace it with another highliter anymore since firefox-7 fixed its regex library.

-- MichaelDaum - 31 May 2013

Closing this one unless there are further insights.

-- MichaelDaum - 12 Oct 2013

ItemTemplate edit

Summary Replace chili with a generic highlighter module
ReportedBy PaulHarvey
Codebase trunk
SVN Range
AppliesTo Extension
Component JQueryPlugin
Priority Enhancement
CurrentState Closed
Checkins distro:4ca5b6460ab1 distro:830a80b26df4
TargetRelease n/a
ReleasedIn n/a
CheckinsOnBranches Release01x01 trunk
trunkCheckins distro:830a80b26df4
Release01x01Checkins distro:4ca5b6460ab1
Topic revision: r12 - 12 Oct 2013, MichaelDaum
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy