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
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... http://codemirror.net/
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
https://github.com/csirac2/src-highlite-foswiki
--
MichaelDaum - 16 Nov 2011
hilite
is fine, I just have trouble typing it (I keep typing
highlight
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:
http://alexgorbatchev.com/SyntaxHighlighter/
--
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