Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Feature Request: Adding Colors to Source Code

by Vautrin (Hermit)
on Mar 06, 2004 at 19:56 UTC ( [id://334522]=monkdiscuss: print w/replies, xml ) Need Help??

Many times, especially when large scripts or modules are posted, I'll have a hard time reading the code because I am used to context sensitive highlighting (namely CPerl Mode in Emacs). Sometimes it gets so bad I cut and paste the code into Emacs to read it. I was curious, what do you think of context sensitive highlighting, and how hard would it be to create it as a feature for Perl Monks? I would be happy to volunteer to work on a module to create code to highlighted text, but could I even get it into Perl Monks? (And is there even a demand?)

Want to support the EFF and FSF by buying cool stuff? Click here.

Replies are listed 'Best First'.
Re: Feature Request: Adding Colors to Source Code
by matija (Priest) on Mar 06, 2004 at 20:05 UTC
    If you do decide to go that way, could you please do the coding through CSS? That way, I can assign colors that I like (or no colors whatsoever) by just selecting the appropriate CSS.

    I suppose the CSS-for-code would best be a separate selection from the-rest-of-site CSS in user settings.

Re: Feature Request: Adding Colors to Source Code
by hossman (Prior) on Mar 06, 2004 at 20:34 UTC

    An alternate approach, that would probably be a lot simpler to impliment, but could help this use case -- as well as may others -- would be to add a single User Setting for controlling the mime/type returned when using "displaytype=displaycode" (ie: when clicking the Download COde" link).

    This way, people could change their user setting to use "text/plain+perlmonks_code" as the mime type, and then configure their browser to use any app of their choice as a helper for that mime/type. Clicking "Viewing Code" would then launch that app -- which could colorize, be an editor, let them run the code in a debugger at the click of a button, whatever they want.

Re: Feature Request: Adding Colors to Source Code
by castaway (Parson) on Mar 06, 2004 at 21:45 UTC

      Syntax::Highlight::Perl - but Im not sure its a good idea..

      I think it is a very good idea, as long as it is a user setting and done using CSS. I know I would love and enable the feature as soon as I can.

      Here is the code I use at http://tnx.nl/scribble.plp:

      perl => sub { require Syntax::Highlight::Perl; my ($data) = @_; my $hl = Syntax::Highlight::Perl->new; $hl->define_substitution( '<' => '&lt;', '>' => '&gt;', '&' => '&amp;', "\t" => '&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb +sp;', ' ' => '&nbsp;', ); $hl->set_format( $_ => [ "<span class=$_>", "</span>" ] ) for qw/Comment Directive Label Quote String Subroutine + Variable Keyword Builtin Operator Package Number CodeTer +m Symbol DATA/; return '<link rel=stylesheet href="/perl.css"><pre>' . $hl->format_string($data) . '</pre>'; },
      I use this together with http://tnx.nl/perl.css. This code using this style sheet renders as http://tnx.nl/2240IXCX (link dies after 30 days).

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

Re: Feature Request: Adding Colors to Source Code
by theorbtwo (Prior) on Mar 06, 2004 at 21:57 UTC

    We have more free web server CPU then we did before, but not that much more. Also, as more uses come to the site, that free CPU will become less free.

    Anyway, as castaway just pointed out to me, a lot of stuff gets put in <code> tags that is not /perl/ code.


    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

      If it was done once on the way into the DB (when a poster hits save) rather than everytime it is displayed it probably wouldn't be too much of a hit on the cpu, but that would still leave the problem of determining perl code blocks from other types of fixed pitch data,


      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
        How difficult would it be to add <code type=perl> or <code type=html> and parse them differently? Or if it's only going to parse Perl then just have a flag to tell it that it is Perl.

        But I think it would have to be a one time parse as it's added to the DB because it would be just too taxing to parse every time code is displayed.

      Yes, CPU usage is a minor concern. But there are ways to make it not such a big deal.

      The specific case that Vautrin seems to be talking about is when somebody has a big block of Perl code that they have pasted into code blocks. In those cases, it can be hard to follow for those of us who have been spoiled with syntax highlighting. I don't think that means that all code blocks need to be highlighted all the time.

      As multiple others have already suggested, if there was a link, similar to the download code link, that was basically a "View code with context markup", then the monks could use that link whenever they wanted to, but otherwise it would take up no more CPU than normal. This also solves the "not all code blocks are Perl" issue.

      Well if CPU usage is a problem, what about a javascript solution? That would take care of the problem of CPU usage. Add in a button to "colorify" the code on the current page and it might work well.

      Want to support the EFF and FSF by buying cool stuff? Click here.
        I've taken the liberty of making an example:

        <html> <head> <title>test</title> <style> code { white-space: pre; } .functionName { color: red; } .reservedWord { color: green; } .stringValue { color: blue; } .comment { color: grey; } </style> <script> function HighlightSyntax(object) { var codeContent = object.innerHTML; //stringValue codeContent = codeContent.replace(/(\"|\')(.*?)\1/g, "$1<span clas +s=\"stringValue\">$2</span>$1"); //functionName codeContent = codeContent.replace(/(sub\s+)([a-zA-Z]\w+)/g, "$1<sp +an class=\"functionName\">$2</span>"); //reserverdWord codeContent = codeContent.replace(/(\s+)(close|else|if|for|foreach +|my|open|print|printf|return|sprintf|sub|unless|use|while)(\s+)/g, "$ +1<span class=\"reservedWord\">$2</span>$3"); //comment codeContent = codeContent.replace(/(\#.*?\r|\n)/g, "<span class=\" +comment\">$1</span>"); object.innerHTML = codeContent; } </script> </head> <body> <code onClick="HighlightSyntax(this);"> #!/usr/bin/perl -w sub JavascriptEncodeText($) { my $string = shift; unless (defined ($string)) { $string = ''; } $string =~ s/([\x{80}-\x{ffff}])/sprintf('&#x%04X;', ord($1))/ge; return "$string"; } #apples print "test\n"; <\/code> </body> </html>
        To try it, remove the backslash in the last <\/code> thing. This could easily be expandedn (i'll work some more on it and post it too.)

      We have more free web server CPU then we did before, but not that much more. Also, as more uses come to the site, that free CPU will become less free.

      On my system, rendering the snippet I posted in this thread can be done 575 times per CPU second on my loaded system. I think nodes get updated much less often and am assuming the PM webserver(s) is/are better than mine.

      Should it *become* a problem, you can always turn it off later. It's not as if adding or removing this feature is a lot of work, given that code that implements it is already available.

      Anyway, as castaway just pointed out to me, a lot of stuff gets put in <code> tags that is not /perl/ code.

      So? There will be some coloured words and characters. That looks funny, but in my opinion is not at all a problem.

      If it were a problem, the introduction of a <perl> tag would solve it instantly. But I don't think it is.

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

Re: Feature Request: Adding Colors to Source Code
by jeffa (Bishop) on Mar 07, 2004 at 00:33 UTC

    There is also Perl::Tidy, which uses CSS ... but as usual, this is a feature request that we don't need.

    Instead, the user can cut and copy the text into her/his editor of choice and read it from there. Or, something like:

    lynx -dump http://perlmonks.org/index.pl?node_id=334560&displaytype=di +splaycode mv index.pl.htm index.pl gvim index.pl rm index.pl
    YMMV

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    B--B--B--B--B--B--B--B--
    H---H---H---H---H---H---
    (the triplet paradiddle with high-hat)
    

      Instead, the user can cut and copy the text into her/his editor of choice and read it from there.

      Of course we can copy and paste. But I'd rather have it in my browser, enabled for every Perl code block.

      It's a bit like having hyperlinks. Sure, you could copy and paste the address, but I have to admit that I kind of like being able to simply point and click.

      We don't NEED anything. It's just something that would be a very welcome addition. Even many PHP fora have syntax colouring. I know we can do BETTER than anything PHP.

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

      Well, that's the thing, I don't think I should have to go through hoops to read the code someone has posted. Syntax highlighting is much more convinient. A good example is php.net. I don't code in PHP often (except when I have to), but when I do, any examples are much easier to read -- especially the verbose ones. Besides, I don't always have a lot of time when I'm on Perl Monks. The extra effort required to view noob code sometimes means I don't have the time to spend on it.

      Want to support the EFF and FSF by buying cool stuff? Click here.

        So you would rather someone else go through hoops instead, eh? I call that false lazyness. First of all, some of us don't even need syntax highlighting - i for one do use it, but i do not rely upon it. When i was cutting my teeth here at Perlmonks i didn't complain about not having enough time to review "noob" code ... i just ran their code through perltidy and rolled with it. It's up to me to find the time.

        It's really quite simple you see, this kind of feature is one that you yourself can implement. Just write a CGI script that accepts a number as it's single param and fetch that node from Perlmonks with displaytype=displaycode. Run through the code through one of the many CPAN modules mentioned and display. Personally, i think this should be a requirement before one can become a Friar. ;)

        UPDATE: One time only? Maybe if you are God ... but most of us mere mortals have to rely on testing and debugging before we get it right. And the more users you have to accomodate for, the more testing and debugging required. Not to mention the committee that must be assembled to agree upon what to implement and what to reject. Give your client an inch and they will want a mile.

        jeffa

        L-LL-L--L-LL-L--L-LL-L--
        -R--R-RR-R--R-RR-R--R-RR
        B--B--B--B--B--B--B--B--
        H---H---H---H---H---H---
        (the triplet paradiddle with high-hat)
        
Re: Feature Request: Adding Colors to Source Code
by zby (Vicar) on Mar 06, 2004 at 20:58 UTC
    There might be problem with the fact that not all code posted here is perl (some is HTML, Template::Toolkit, some shell, C etc). Of course there allways could be additional button to set if the code is indeed perl.
      Well it seems to be elementary to figure out whether code is Perl or not. For instance, if code contains semicolons at the end of most new lines and commonly used perl keywords / variables (i.e. $_, @_, @ARGV, shift, pop, push), theres a very good possibility that it's Perl. So a button wouldn't even be needed.

      Want to support the EFF and FSF by buying cool stuff? Click here.
Re: Feature Request: Adding Colors to Source Code
by davido (Cardinal) on Mar 07, 2004 at 04:53 UTC
    I don't know that I'm sold on the need. Syntax highlighting is cool, but as often as not I find that many editors prove the old adage that "Only perl can parse Perl" (ie, highlighting is occasionally goofed up by odd syntaxes).

    Combine that with the fact that code tags are used for a lot more than just Perl code, and you end up with a difficult to implement problem.

    As far as readability, I don't really find syntax highlighting all that big of a deal anyway. If you write clean code, with proper indenting, sufficient whitespace, and clear idioms, you end up with something that is going to be legible with or without highlighting. If you want to write illegible code, we have a section for that too, and I have a feeling syntax highlighting won't help there either.


    Dave

      find that many editors prove the old adage that "Only perl can parse Perl" (ie, highlighting is occasionally goofed up by odd syntaxes).

      I've rarely seen Emacs mess up on the syntax highlighting. Certainly, it's happened, but it's not really that common. Besides, if we changed the colors of the strings, and changed the colors of the keywords, how hard is it really? Not that hard at all.

      Combine that with the fact that code tags are used for a lot more than just Perl code, and you end up with a difficult to implement problem.

      I've pointed out in another post that Perl is very unique and structured. For instance, HTML doesn't have semicolons at the end of most of the lines, and #! /usr/bin/perl or use strict; use warnings; at the top of most (if not all) scripts are dead giveaways as to perl. Add to that a couple checks for variables that you're only going to see in Perl -- i.e. $_, @_, @ARGV, things that look like variables -- or variables with my before them, and it's really not that hard to identify Perl.

      As far as readability, I don't really find syntax highlighting all that big of a deal anyway. If you write clean code, with proper indenting, sufficient whitespace, and clear idioms, you end up with something that is going to be legible with or without highlighting. If you want to write illegible code, we have a section for that too, and I have a feeling syntax highlighting won't help there either.

      Unfortunately, this is a place where there are quite a people who don't write clean code. Granted, well structured code can be easy to read whether or not it's highlighted. However, what percentage of posts have that structure? Again, if I see a mess on the screen, my first instinct is to want to help out, but I really don't have the time to sort through code. Adding colored strings / keywords / variables / whatever would go a long way in helping to untangle the mess some people post.


      Want to support the EFF and FSF by buying cool stuff? Click here.
        For instance, HTML doesn't have semicolons at the end of most of the lines ...

        There is a "view source" link on most of the pages on my web site. For CGIs, it shows you the perl source. The generated HTML might look something like this:

        <html>... <tt> use&nbsp;CGI::Carp&nbsp;qw&nbsp;(fatalsToBrowser); <br>use&nbsp;strict; <br>use&nbsp;warnings; <br>use&nbsp;Data::Dumper; <br> <br>use&nbsp;IO::Capture::Stdout; <br>use&nbsp;IO::Capture::Stderr; <br> <br>print&nbsp;"Content-type:&nbsp;text/html\n\n"; ...
        The view source program is, of course, just a CGI and so you can view its source too. But don't bother, it's awful code.
Re: Feature Request: Adding Colors to Source Code
by jonadab (Parson) on Mar 07, 2004 at 02:50 UTC
    Sometimes it gets so bad I cut and paste the code into Emacs to read it

    Copy and paste? What, you mean you're not reading Perlmonks from within Emacs in the first place?


    ;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print
      No, I don't surf the web from Emacs. I believe that the Internet is a graphical medium, and as much as I like Emacs, text just doesn't cut it.

      Want to support the EFF and FSF by buying cool stuff? Click here.
        The Internet and the web aren't the same thing. The Internet is an infrastructure, and saying it's a graphical medium doesn't make sense. The web itself is a collection of services, none of them being graphical by nature. Perhaps you want to say that experience HTTP services by means of a device that's able to display graphics. So be it, but there isn't much graphical content on Perlmonks, and authors don't have the ability to inline graphics in their articles.

        Abigail

Re: Feature Request: Adding Colors to Source Code
by Abigail-II (Bishop) on Mar 08, 2004 at 10:03 UTC
    I'll have a hard time reading the code because I am used to context sensitive highlighting
    I think this is a very serious handicap for a programmer, and the solution should be to make yourself less dependent on highlighting.

    Abigail

Re: Feature Request: Adding Colors to Source Code
by Kage (Scribe) on Mar 06, 2004 at 22:48 UTC
    Something else that'd be cool is a link suffixing all <code> tags (this link can be turned off in the user settings) that allows you to view the code inside the tag in plaintext, unedited (no width cuts).
    “A script is what you give the actors. A program is what you give the audience.” ~ Larry Wall
      Are you not aware of the d/l code link that magically appears whenever a post contains code tags?

      jeffa

      L-LL-L--L-LL-L--L-LL-L--
      -R--R-RR-R--R-RR-R--R-RR
      B--B--B--B--B--B--B--B--
      H---H---H---H---H---H---
      (the triplet paradiddle with high-hat)
      
Re: Feature Request: Adding Colors to Source Code
by dada (Chaplain) on Mar 08, 2004 at 12:17 UTC
Re: Feature Request: Adding Colors to Source Code
by demerphq (Chancellor) on Mar 08, 2004 at 19:56 UTC

    I think that there is a simple workaround that resolves some of the issues with syntax highlighting and the site. The solution involves adding to the standard PM CSS a set of attributes that cover the classes output by Perl::Tidy and a change in whether the 'DIV' and 'SPAN' tags are allowed by the site. (The last time i looked PerlTidy uses DIV and SPAN blocks with class info to do the highlighting.) This way people that want to post highlighted code will at least have the code renderable by PM, and that there will be the appropriate CSS to go along with it. Thus all they need to do is run perl2html on the code, and then paste it into their node.

    Of course this means the CSS for each theme is adjusted and a bunch of other work, but at least its doable. At least I think it is. Maybe there is a good reason im overlooking that DIV and SPAN tags are prohibited by the site.


    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi


Re: Feature Request: Adding Colors to Source Code
by no_slogan (Deacon) on Mar 09, 2004 at 06:32 UTC
    Ugh. Syntax highlighting drives me straight up the wall. If someone decides they just have to put an antifeature like that in the site, I hope they at least make an easy way to turn it off. There are so many editors where you have to turn off each color one at a time. Color for keywords? Black on white. Color for integer literals? Black on white. Color for string literals? I ended up writing a perl script to disable all of the highlighting in Kate.
Re: Feature Request: Adding Colors to Source Code
by bageler (Hermit) on Mar 09, 2004 at 18:29 UTC
    perl is a parsing language, you should easily be able to code to determine what type of code is in a <code> block. I think it's a good idea, as others have said implemented in CSS

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: monkdiscuss [id://334522]
Approved by BazB
Front-paged by ehdonhon
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2024-03-19 11:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found