Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Improvement of < code > sections

by spx2 (Deacon)
on Aug 28, 2009 at 20:57 UTC ( [id://792017]=monkdiscuss: print w/replies, xml ) Need Help??

Hi,

I was recently reading a post here on Perlmonks but the code in it was not indented properly so I had to copy&paste it in my editor and indent it there and benefit from the syntax highlighting. It would be nice if syntax highlighting and perltidy were applied to < code > sections of Perlmonks threads(perltidy on serverside and highlighting can be on both server/client side). If this exists already please let me know how to turn it on. I am asking this because for example stackoverflow has this feature and it turns out to be very effective and useful.

Best regards,
Stefan

Replies are listed 'Best First'.
Re: Improvement of < code > sections
by GrandFather (Saint) on Aug 29, 2009 at 02:00 UTC

    Messing with the author's formatting would often remove information about the stage of author's Perl journey. That information can be important in terms of asking the right questions for follow up information and for determining the level replies should be aimed at, and possibly even for judging how much the author actually cares about the question.


    True laziness is hard work
      would often remove information about the stage of author's Perl journey

      What kind of information are you referring to ?

      how much the author cares about the question

      This is arguable , but I tend to agree.

      To clarify what I mean , please take a look at this code which was posted on gist , doesn't the syntax highlight look nice ? Do you like it ?

        Your example looks quite badly indented, actually. And I find the colors (insert fancy word for "ugly" here). The contrasting rendering of the letters is distracting and makes the code harder to follow. The extra dark letters have strokes that bleed together, making them harder to read, the "m" looking mostly like a rectangular smudge, the "y" like some sloppy triangle, the square brackets looking at first like vertical bars. The light blue and green are indistinguishable (it wasn't until the fourth viewing that I even noticed that there was more than one cool pastel text color) and look rather washed out against the tinted background.

        And that didn't even include any misapplications of "syntax highlighting" (at least that I noticed).

        I'd be quite shocked if stackoverflow is automatically re-indenting code posted there (as you seemed to claim in your root node). I certainly don't want the code I post here re-indented and I certainly don't want to see some indenting other than that done by the author unless I am able to toggle such drastic rewriting (with the default being that such rewriting is not done).

        I wouldn't be surprised if stackoverflow was using some low-impact, language-agnostic, common-keyword-recognizing, common-quoting-scheme-recognizing, "syntax highlighting". In fact, visiting stackoverflow (and taking quite a while to remember how to log in there) I find no evidence of it re-indenting my unindented code. And I find evidence of it using pretty much what I said in the first sentence of this paragraph. It was quite easy to come up with common Perl constructs that it highlighted incorrectly (// is assumed to start an end-of-line comment, for example). Most Perlish quoting is not properly handled.

        At least the coloring at stackoverflow is so very subtle as to not be very distracting (and no use of bolding), but that is only appropriate as the very generic nature of the highlighting means that it can easily be wrong (depending on what language or non-language the blocked text actually contains -- certainly often wrong in the case of Perl code).

        So I think you are quite mistaken in your original impression that many sites automatically re-indent code. My experience is that such an activity can so easily go astray that it wouldn't be long before such a feature were abanodoned (seriously changing the apparent meaning of code need only happen a very few times before such drastic attempts at enforced aesthetics lose favor, surely). I expect most who thoroughly consider the idea would at least be conerned about potential problems with it, especially for Perl code.

        As for just adding some color to the contents of <code> tags at PerlMonks, I have plenty of experience with code being strangely (or "badly", depending on how charitable I want to be) written because writing the code more sanely illustrates a bug in some syntax highlighter. And I almost never use syntax highligting myself but I've still run into many such cases (and I never use it for Perl code and most of the bad examples are for Perl code).

        There actually have been very rare times when I've found syntax highlighting helpful. They were always when I missed something small but drastic like an unclosed quotation or an unclosed comment (in SQL, FYI -- and SQL usually has really sucky error messages so the extra help is more appreciated there). But I find incorrectly highlighted code to be a much more serious problem than I find correctly color-coded code to be a help, especially for the high-impact things like the highlighter thinking way too much is quoted.

        And I find giving vague color hints that are sometimes going to be incorrect hints to newbie Perl coders on a site like PerlMonks to be a pretty bad idea as well.

        And I have yet to notice stackoverflow offering users a choice of color schemes and having quite a few users who have customized their own color scheme still further. So I doubt anybody could produce a code colorizer for PerlMonks that didn't produce ugly even unreadable results for quite a few members.

        So any syntax highlighter one picks is going to get some things wrong for Perl code (which isn't the only thing put into CODE tags here, of course). So it should be up to the person who is choosing to use a syntax highlighter to pick one whose quirks don't outweigh its benefits to them. For me, my choice is "none". But many make other choices. If there is a syntax highlighter that you like, then arrange to use it in your client. We even supply tools to assist in such client customization. Running into bugs and quirks in a syntax highlighter that was forced upon you by some site admin surely quickly becomes very frustrating. Let's not go there.

        - tye        

        What kind of information are you referring to ?

        As people develop their programming style they also tend to develop a preferred style of code layout. Often the layout of the code can convey something of the author's level of expertise and experience. Reformatting tools strip that information out, but at least if the author does the reformatting it shows a higher degree of interest in obtaining a good answer.


        True laziness is hard work
        No, it doesn't look nice. I've never seen any syntax highlighting that "looks nice". In fact, I find anything that isn't dark (black) on a lighter background distracting. So does any colour scheme that uses more than one foreground colour.

        Now, sometimes distraction is good. For instance, if you want to display an example, and you want to attract the attention to a specific construct in the middle of line 3. Then it's ok to colour this in a different way - it'll distract from the context, and focusses on the important part.

        But code in red, green, purple and six shades of yellow? Horrible.

Re: Improvement of < code > sections
by planetscape (Chancellor) on Aug 30, 2009 at 18:37 UTC
Re: Improvement of < code > sections
by bv (Friar) on Aug 28, 2009 at 21:24 UTC

    Nice idea, but I doubt the obfu folks would take too kindly to it. Plus, I've never seen a syntax highlighter that gets everything right (though that wouldn't necessarily be all bad).

    Maybe an opt-out feature?

    <code notidy nocolor> print "hello, PM!"; </code>

    or something similar

    $,=' ';$\=',';$_=[qw,Just another Perl hacker,];print@$_;
Re: Improvement of < code > sections
by ELISHEVA (Prior) on Aug 30, 2009 at 13:09 UTC

    As far as indenting is concerned, I agree with GrandFather. I also use indenting style (or lack thereof) to get a read on where people are. Experienced coders will go to great lengths to line up their code because it makes a huge difference in their ability to detect bugs and understand program flow. I tend to read confused or missing indenting generally to mean that someone either (a) still doesn't fully understand flow of control concepts or (b) doesn't grasp how important they are to understanding code. I will assume the need to spell out concepts rather than hint at them. I might take the time to be extra encouraging.

    However, I do like syntax highlighting and am frankly very puzzled by the strong antipathy to it. Of course, it isn't perfect, but then again neither are my eyes. All the same, I find I am more likely to miss mistakes when I read code without highlighting than I am with highlighting - and that is even accounting for the odd parser mistake here and there. I use Xemacs Perl syntax highlighting all the time despite its bugs.

    I don't like the idea of forcing highlighting on people, but I do think that the average reader of code is likely to benefit if we provided syntax highlighting by default. Even if the syntax highlighting did little more than mark keywords and literals, there would be a net gain. Of course, it goes without saying that any addition of syntax highlighting would have to be accompanied by a very easy way for syntax highlighting haters to turn it off.

    If we did have syntax highlighting, I would also like to see an attribute on the code tag that allowed an author to turn highlighting off on a case by case basis. We also surround error messages and program output with code tags. These would not look right at all if they were color coded as if they were Perl code. Color coding would also be counter-productive to certain kinds of code, like obfu. And I also feel an OP should have the editorial freedom to reject color coding on his or her own posts as a matter of course if they dislike it strongly enough.

    On a technical level, adding syntax highlighting would represent a major change to PerlMonks. We would have to change the way we rendered the web pages in several different places, add additional user settings, add a user interface to turn it on and off, and so on. Any such change would take some serious commitment from the gods because no code can be added or patched without their having the time to review a complex list of interconnected changes and approve them.

    Best, beth

Re: Improvement of < code > sections
by LanX (Saint) on Aug 28, 2009 at 21:23 UTC
    I think reintendation can only be implemented as a voluntary option for the author, and not as an automated action, which questions the benefit you're expecting...

    Cheers Rolf

    UPDATE: And don't forget, <c> tags are already used for many things perltidy can't handle!!! (e.g. to display uninterpretated tags like <c> ;-) So we would need a new tag like <perl> to do this.

    UPDATE2: There are at least ten older threads about this topic...

      yes , your suggestion is similar to what bv said , that of having an opt-out tag for doing this. I agree that PM should be flexible regarding what will be formatted/indented/syntax highlighted or not.
Re: Improvement of < code > sections
by ww (Archbishop) on Aug 28, 2009 at 21:24 UTC
    We'd certainly be pleased to have you offer code to do so to PmDev for review and possible adoption.
      if granted permission I will write code for PmDev(until now I haven't been able to do this).
Re: Improvement of < code > sections
by Anonymous Monk on Aug 28, 2009 at 21:24 UTC

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (3)
As of 2024-03-28 17:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found