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?)

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.

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.

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,

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.

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.

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

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.

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.

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.

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.

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.

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

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.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other