The syntax highlighting macro that we’re promoting by default in XS is currently the
This macro has several problems:
- Performance: It’s written in python and we have to use jython to execute it. This makes the macro very slow on the first usage (since jython is being loaded) and even for subsequent calls, it’s still a lot slower than it could be (and quite slow for large content to style).
- Features: it’s missing several features such as line numbering, copy the content with a button, etc.
I think there are 2 options.
- Move the current code macro to xwiki-contrib and add a new macro to XS.
- Main issue: users need to install the code macro. Note that since we support discovering macros, it’s not that hard as our UI will propose that.
- Secondary issue: The
codename is quite code for a macro. For new macros, we would need to find names for them. One idea is to name them after their technology so that we could support several and if we change it in the future, we won’t have again a problem of naming. Example:
- Make the code macro a generic macro that can support several implementations (through Components)
- Offer an Admin UI screen to change the code macro implementation (dynamically list all supported implementation in the current xwiki instance)
- Move the current code macro to contrib but refactored as a Component for the new generic code macro
- Introduce a new Component for the new code macro that uses some existing js framework such as highlight.js, prism.js or some other.
- Main complexity: map the parameters of the existing code macro to the different implementations. Basically this means keeping existing pygments language ids and each impl would map them to their internal names. Same for other parameters (layout and source) but that doesn’t seem too hard.
To recap, there are 2 decisions to take:
- Choose a way to do that