http://www.perlmonks.org?node_id=712066

Has anyone thought about integrating a code-to-html syntax highlighter with the <code> tags? e.g., <code style="perl">...</code>" (probably most prevalent)? I see that Code2HTML could do the heavy lifting, though the HTML it produces is kind of sub-par (not very CSS friendly), yet there's PPI::HTML which would do the same thing just for perl, but much more CSS-friendly. I'm sure there are many other examples out there that could be used (such as many of the pastebin's), too.

I don't know about you, but I spend most of my time with perl code in a syntax-highlighting editor. I find it helps me focus on structure, making it easier to zoom in on chunks. So when someone posts 70 lines of perl code, I find it more difficult to read on the site just because the computer isn't helping me decipher the code.

Now, of course if someone did this, it would need to be an option in your user settings to turn it off. The other downside would be the CPU time required for rendering this, so a cheap/fast renderer would be required, which could mean native code. I'm not saying it'd be easy, but I think it could really make some aspects of the collaborative nature of the site much nicer.

Replies are listed 'Best First'.
Re: Syntax highlighting code tags
by kyle (Abbot) on Sep 17, 2008 at 17:27 UTC
Re: Syntax highlighting code tags
by rhesa (Vicar) on Sep 17, 2008 at 19:01 UTC
    I use Free Nodelet hack: Syntax colouring. It's nice, and doesn't impose additional load on the PM server. I've put the relevant JavaScript and CSS files on my own server just in case (and for easier tweaking).

    The fact that it's JS has one drawback: it can choke on big nodes with large <code> sections (and my experiments with setTimeout were unsuccessful — my JS fu is negligeble). But I find that, in practice, it's not a big deal.

Re: Syntax highlighting code tags
by Your Mother (Archbishop) on Sep 17, 2008 at 18:07 UTC

    A client-side solution could be nice. I suspect the site performance would suffer if a couple dozen additional "scripts" were being parsed by the server every other page load. There are some decent JS syntax highlighters. Maybe we could have something like Chili available through user settings. It wouldn't do as correct a job on the markup as PPI but it could still be nice and does decent markup on a variety of other languages which get posted too (XHTML, Java, JavaScript, SQL, etc). Would have the side-effect of making jQuery available on the site which would open up many other possibilities; if desired.

      If this can be implemented so that the highlighting happens after a node has been created/edited, and the result can be cached as HTML, the impact on the site's performance should be neglectible.

      I would like to recommend to let the author decide whether or not a piece of code should be highlighted (i.e. not make it configurable in the User Settings). The reason is that syntax highlighting tools are not always perfect. Sometimes highlighting makes the code look really bad. (Moreover, <code> tags don't always contain Perl code.) If the author notices that, they can choose to either reformat the code or disable the highlighting.

        I would like to recommend to let the author decide whether or not a piece of code should be highlighted (i.e. not make it configurable in the User Settings).

        I think you raise a good point but I think that you need to consider this idea more carefully from more angles.

        For example, I don't care what you or any other author decides, I don't ever want to see rainbow code (at PerlMonks when I'm logged in). So it needs to be a choice of the viewing user. You make a good point about there being value in it also being a choice of the author.

        However, I don't care what burden you hope to put upon authors about declaring what type of code they have posted nor hoping they will check whether the syntax highlighting is doing a good job on their code; I won't be shouldering that burden for chunks of code that I post and I don't think it is reasonable to expect all authors to (and trying to do that would be doomed to failure anyway, IMHO).

        But the more I consider this idea, the more I think it is doomed. Perl syntax highlighting imperfect (always, at this point) and so it is a reasonable option to select to follow for your own code. However, trying to get some other person to bend to the idiosyncracies of the Perl code highlighter that somebody else chose will always just be aggrevating, even unacceptable to some people. This will just be another source of strife.

        So the choice of the highlighter needs to be in the control of the viewing user and the viewer needs to be able to disable it when it fails.

        - tye        

        I like that; in addition to letting the user decide whether they get any highlighting/JS. It sort of has to be author controlled anyway because the author would need to choose what the code snippet syntax was -- Perl, SQL, XHTML, etc.

        Style attributes -- like <c style="whatever">snippet</c> -- probably shouldn't be supported because it would add a bunch of sanitization parsing if it's literal HTML style and plain old parsing/logic if it's not real HTML. Classes would be easy and innocuous. <c class="xhtml">snippet</c>. Or, in the spirit of <c/> pseudo-tags <perl>say "hello"</perl>. I actually used that idiom in a server side PPI driven highlighter. Using it for a year or so I'm kind of luke warm on that approach.

        I really like the idea of Chili after thinking more about it. I believe there are a couple of syntax files for it to do Perl floating around but it would be great if the community could own the definitive version. It would certainly be vetted better just by being used here than it would be as any sort of independent release.

        I doubt it'll happen and I won't cry if it doesn't but it would be fun. I volunteer to work on it if it gets some steam and needs an extra hand.

Re: Syntax highlighting code tags
by parv (Vicar) on Sep 18, 2008 at 04:04 UTC

    Syntax highlighting, by default non-garish & off, would be tolerable only if everybody formats their code. Ability to use reader (as in not-an-author person) specified CSS would make the feature practical.

    In any case, pushing the code through perltidy would be more desirable than this. (I know this point also has been discussed before.)

      Of course, pushing <code>s through perltidy only works if the code is perl. As well as perl code, (including chunks of code that won't parse because they were full of '...' placeholders), I've posted shell scripts, C and PostScript here.

        Yes, that is quite a possibility ... just as much as (possibly, forced) implementation of a(ny) pretty printer here.