Item1353: cannot use multiple syntax highlighters simultaneously

If both are installed and enabled then the DpSyntaxHighlighterPlugin takes over and the SyntaxHighlightingPlugin will not be used.

There is the possibility missing to force usage of one of the plugins per defined CODE section. To fix the issue there possibly could be some additional parameter that tells which plugin is supposed to be used, e.g. plug="SyntaxHighlightingPlugin".

In my case I'd like to use the DpSyntaxHighlighterPlugin for the XML related stuff and the SyntaxHighlightingPlugin for the shell related ones (bash, csh, ksh, sh).

-- IngoKappler - 22 Mar 2009

this is an interesting use case, one which wasn't considered. indeed, the idea was that one could change syntax highlighters without changing any topic code, as all (we had up to 4 at one time, iirc) syntax highlighters used the same CODE syntax. in any case, having an additional parameter to specify which renderer sounds like a bit of a nightmare, with plugins having to forward requests to other plugins (if they're even installed and enabled). perhaps each syntax highlighter could additionally define a CODE_renderer, eg, CODE_DP, etc.

-- WillNorris - 23 Mar 2009

Hmm. I recognized that there was an effort to move all the highlighters to use the CODE macro but I also remember I had a similar issue with (tm)Wiki where I already found that I couldn't use different highlighters at the same time without issues. Now is the time to address it. There will always be differences regarding the supported languages and I consider it a very likely use case that one may want in one case this plugin and in another one the other. This gives most flexibility and features to the users. If my proposal leads to a nightmare then please ignore it. I am sure there will be better solutions. I just want to suggest to consider the issue, thanks a lot for all those powerful plugins.

-- IngoKappler - 23 Mar 2009

This is something I have thought about before. I think Will is right, it would be a bit of a nightmare. However, it could be done so that each plugin additionally recognises either CODE_DP or CODE_ENSCRIPT (maybe better name?), as well as CODE. If you would like this then its a 5 min job that I don't mind doing for you.

Another alternative would be to have a wrapper plugin that forwards the request on to which ever plugin is specified. Still pretty messy though, don't think plugins were designed to talk to each other!

-- AndrewJones - 23 Mar 2009

Sounds as if adding an additional parameter like CODE_DP or CODE_ENSCRIPT is the cleaner and easier solution. That's fine for me as it will solve my issue although at the cost of the common CODE macro. In my case using CODE then would use the DpSyntaxHighlighterPlugin while for the SyntaxHighlightingPlugin I would be forced to use CODE_ENSCRIPT. It appears logical to me that this kind of default behaviour could be changed by defining a different order in PluginsOrder of configure. I now tested the order by setting PluginsOrder to TWikiCompatibilityPlugin,SpreadSheetPlugin,SyntaxHighlightingPlugin and then the system first tries to use SyntaxHighlightingPlugin instead of DpSyntaxHighlighterPlugin. So people already have a mechanism to define which plugin should be the default for using CODE.

I don't feel so good about the wrapper plugin. Having something like that the question is what if there are 2 or more alternatives and not just 1. Could them all be specified and how does that plugin decide then? It could be nice to have e.g. something like a preferred highlighter and if the definition doesn't match that then the next one is tried and so forth (defined order). This would allow a hierachy of plugins which are tried top down at the cost of plugin design principles (shouldn't talk to each other) and easy implementation because maybe any newly supported language may need to be added to the wrapper as well (very dirty so a real solution should be more intelligent).

Conclusion:

Add the additional CODE_DP or CODE_ENSCRIPT as it is clean and easy (5 minutes) and update the documentation with a short explanation about pros and cons versus CODE. Add also a note that the default plugin which should be used with CODE can (must if not by nature the first that is found) be defined via PluginsOrder.

If anyone feels challenged to test/experiment with a wrapper it can still be done, maybe only when a third highlighting plugin arrives at the horizon. The interesting thing about it would be to have the wrapper identifying which of the installed plugins is the first one in the defined order that will provide the capability to render the section with the given language thus allowing to only use CODE and leave the intelligence to the wrapper (makes any manual adjustments superfluous).

-- IngoKappler - 24 Mar 2009

Ok I will add the CODE_DP and CODE_ENSCRIPT to the plugins when I get a chance, hopefully by the weekend. I will probably have the new syntax turned off by default so it would need to be enabled through configure. When enabled, the plugin will listen for both and the first plugin listed in PluginsOrder will handle the standard CODE.

-- AndrewJones - 24 Mar 2009

i wouldn't bother turning off the new syntax by default and enable via configure. sounds like an awful lot of work (for the user that wants to use it), and needless programming as well, imho.

-- WillNorris - 25 Mar 2009

Sorry it took a bit longer to get this done but I have now uploaded new versions of DpSyntaxHighlighterPlugin & SyntaxHighlightingPlugin that have support for =%CODE_DP% and %CODE_ENSCRIPT% respectively.

Not too sure about the documentation I wrote, so feel free to make some changes.

-- AndrewJones - 29 Mar 2009

Thanks a lot! Just tested %CODE_ENSCRIPT{lang="ksh" num="1"}% ... %ENDCODE% and it now can be used in parallel to the "default" DpSyntaxHighlighterPlugin which in my installation takes the default %CODE% blocks.

-- IngoKappler - 01 Apr 2009