I'm having a hard time to find a few minutes to reply to the large number of incorrect assertions in this thread.

Nodes are not rendered before they are inserted into the database and making that happen even in part is no simple task. It will never happen in total as there are user settings that affect how nodes are to be rendered. Doing some partial rendering and having to keep multiple versions of each node in sync sounds like a complex design that, in my experience, would lead to a lot of unintended complications.

So the increased load will not be per node update as you appeared to assume but per node display. This would probably be a significant load even if we went with the faster but worse of your suggested solutions.

There is no code to do syntax highlighting that also works with PerlMonks code wrapping options. Having the two behave together would not be trivial work.

It is nice that you think you won't mind having non-Perl or pseudo-Perl be highlighted incorrectly. Try to think about other people for second. Do you really think everyone who posts some code related to their problem will just shrug and say "no point in complaining about the whacky colors being forced upon my input, it is a tiny price to pay for the wonder that is syntax highlighting and I'm so happy I have that"?

Yes, please, let's add a <perl> or <code type="perl"> tag to a mark-up system that people are already complaining is too complicated. For one thing, I won't be wasting my time trying to decide whether the code I post is suitable to be highlighted or not so my code will remain in plain CODE tags and wouldn't be subject to highlighting. So we'll get to enjoy lots of whining and considering and janitorial thrashing arguing about whether each bit of code should be marked for syntax highlighting or not and whether janitors should be making such changes.

And you want us to use the acknowledge worse of a couple of syntax highlighters. Syntax highlighting is a fine compromise to make with yourself. You imposed the somewhat broken highlighter upon yourself so you can choose whether it is a net win for you to avoid the constructs that confuse it or to remove the broken highlighter. Having someone else choose a syntax highlighter for you is going to be a source of conflict. Even the best syntax highlighter doesn't get all Perl code right. I really don't look forward to the volume of complaints about code being highlighted incorrectly.

I find it very inappropriate to have PerlMonks not support certain Perl constructs because they get highlighted incorrectly (and some will interpret it that way either criticizing people for posting such constructs and not checking that the code they posted was highlighted correctly or criticizing PerlMonks for not highlighting their code correctly).

I often post Perl pseudo code which I'm sure some will be completely unable to read without their pretty colors assigned to bits yet the highlighter won't be able to parse because I wrote "You'll need to insert code here" and every reader can understand what I meant but no syntax highlighter does.

So, since you find this such trivia to provide, then write an external solution such that clicking "download code" pops up a web page containing highlighted Perl code. A user setting to contol the Content-Type as suggested by hossman might be helpful. Or you could write it as an HTTP proxy and even implement Vautrin's trivial automatic Perl code detector so that only Perl code gets highlighted (and it wouldn't be limited to just PerlMonks).

Since this is such a vital feature, I'm really surprised that you haven't implemented this already. It will just take you a couple of minutes, I'm sure.

Nodes are not rendered before they are inserted into the database and making that happen even in part is no simple task. (...) So the increased load will not be per node update as you appeared to assume but per node display.

I assumed there was some kind of node cache and didn't think about user settings. When nodes are rendered on request, I can think of many reasons for not syntax colouring code.

(Pseudo code)

I very often provide pseudo code. Even for that, syntax colouring can work very well.

then write an external solution such that clicking "download code" pops up a web page containing highlighted Perl code.

If I'm writing anything, it will be for inline code tags.

Or you could write it as an HTTP proxy and even implement Vautrin's trivial automatic Perl code detector so that only Perl code gets highlighted (and it wouldn't be limited to just PerlMonks).

Hm, I like the proxy idea and will probably give it a try soon.

Since this is such a vital feature, I'm really surprised that you haven't implemented this already. It will just take you a couple of minutes, I'm sure.

It is simple to implement the Perl tools needed for this in a framework that is also Perl. It is, however, not quite as trivial to implement this in something that doesn't support Perl, mostly because the two reasonably good tools available to colour Perl are both written in Perl. Any solution involving the d/l code link would be much easier, but that isn't what I'm interested in. It is extra work when reading the site - I want the *inline* code blocks to be rendered in a pretty readable way.

Should anyone know how to hook something like this into Mozilla, please let me know. I've tried looking for this holy grail but have not yet found it.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Hm, I like the proxy idea and will probably give it a try soon.

It is simple to implement the Perl tools needed for this in a framework that is also Perl. It is, however, not quite as trivial to implement this in something that doesn't support Perl [...]

Should anyone know how to hook something like this into Mozilla, please let me know.

I think Perl supports HTTP::Proxy (though not prior to v5.8) and I think even Mozilla supports HTTP proxies.

- tye