12

Possible Duplicate:
Syntax highlighting hints

As we all know, prettify.js, which is used by Stackoverflow for syntax highlighting, allows the specification of the intended language. However, we cannot reach this from our posts, so that syntax highlighting mangles everything that is not C or one of its derivatives.

There seems to be a simple solution: Allow the specification of a class attribute for code tags, so that we can supply prettify.js with the language we intend:

<pre> <code class="prettyprint lang-foo"> ...

I hope that this can either be implemented, or that someone gives a compelling hint to why this might not be feasible.

Perhaps it is even implemented somewhere, but lacking documentation.

9
  • dupe: meta.stackexchange.com/questions/981/syntax-highlighting-hints
    – balpha StaffMod
    Commented Mar 6, 2010 at 19:41
  • 3
    NO, NOT DUPE! This is a very specific question regarding a solution to the problem shown in about a thousand requests and complaints.
    – Svante
    Commented Mar 6, 2010 at 19:44
  • 2
    No need to yell. And yes, I get your point, and it's a judgement call. I still think this should be an answer on that question and not a question. Also remember that the canonical way to represent code in SO questions is the markdown 4-space-indent way, not <code> tags.
    – balpha StaffMod
    Commented Mar 6, 2010 at 20:06
  • 1
    @balpha: Sorry for the capitals, but I feared that people may just see the familiar dupe comment and close without reading the question. I know the canonical way, but the canonical way is apparently ill suited for incorporating needed explicitness.
    – Svante
    Commented Mar 7, 2010 at 1:32
  • @Svante Just some advice, I don't think WRITING IN CAPS will successfully turn a tide of close-votes. In fact, it may only add momentum.
    – Sampson
    Commented Mar 7, 2010 at 1:35
  • Also, Stackoverflow being addressed at professional programming, I find it hard to understand that seeking a remedy for broken syntax highlighting should provoke shrugging it off as a "judgement call".
    – Svante
    Commented Mar 7, 2010 at 1:35
  • @Jonathan Sampson: I agree wholeheartedly that writing in capitals should be an instrument only for very narrow circumstances.
    – Svante
    Commented Mar 7, 2010 at 1:44
  • I think you misunderstood what I was saying. The "judgement call" just referred to the whether this is a dupe or not. I'm totally on your side regarding the actual issue; I have an open prettify question myself. And regarding all caps: No harm done. But you should be aware that this "drawing attention" is done way more effectively with bold text than with ALL CAPS. Cheers :)
    – balpha StaffMod
    Commented Mar 7, 2010 at 7:57
  • @balpha: I am sorry for misunderstanding you. Thanks for the tip with bold text.
    – Svante
    Commented Mar 7, 2010 at 10:22

3 Answers 3

3

I'd love this for CSS:

element#id    { color:blue }
element.class { color:blue }

# is confused in this context.

2
  • It would also be great to be able to turn off // as a comment for Perl. // is never a comment in Perl. Commented Mar 7, 2010 at 5:00
  • I think the OP was suggesting the ability to explicitly declare the type of highlighting you would like to use adhoc.
    – Sampson
    Commented Mar 7, 2010 at 5:03
0

I'm going to go a bit for Devil's Advocate:

Is it really such a big problem? My opinion of this might be a bit biased as I lurk in the SQL, Python and every now and then Java tags, which might not be hit as bad, but after all the code is there, for the human to parse it. I generally just ignore syntax coloring, as it benefits long chunks of code, and you shouldn't be posting large chunks of code.

That being said, this could be helped a bit if the language could be inferred from the tags. That way, this fix would work retroactively, and the work flow wouldn't change.

-3

syntax highlighting mangles everything that is not C or one of its derivatives

This is a bit of an exaggeration..

http://google-code-prettify.googlecode.com/svn/trunk/README.html

The comments in prettify.js are authoritative but the lexer should work on a number of languages including C and friends, Java, Python, Bash, SQL, HTML, XML, CSS, Javascript, and Makefiles. It works passably on Ruby, PHP, VB, and Awk and a decent subset of Perl and Ruby, but, because of commenting conventions, doesn't work on Smalltalk, or CAML-like languages.

This is now implemented. In addition to tag inference (a recent change), you can manually specify the language as a hint to Google Code Prettify.

The spec is:

<!-- language: lang-or-tag-here -->

    code goes here

<!-- language: lang-or-tag-here -->

    code goes here

You may use either a tag or a prettify language code to specify, though prettify language codes are always guaranteed to work regardless of what language the tag happens to be set to.

The complete list of supported prettify code languages is:

  • lang-none
  • lang-default
  • lang-bsh
  • lang-c
  • lang-cpp
  • lang-cs
  • lang-csh
  • lang-css
  • lang-hs
  • lang-html
  • lang-java
  • lang-js
  • lang-lisp
  • lang-lua
  • lang-ml
  • lang-perl
  • lang-php
  • lang-proto
  • lang-rb
  • lang-scala
  • lang-sh
  • lang-sql
  • lang-vb
  • lang-xml
5
  • 8
    This "should work" is a nice expression of hope, but the reality to be witnessed on Stackoverflow looks quite different. Perl regularly gets hit by //, VB by ', Lisp by # and '. Since presumed comments are "greyed out" visually, this confusion with comment characters is especially annoying. However, my main issue is not addressed here: Is the proposed solution feasible? You already have whitelisted attributes for some HTML tags, so the technical provisions seem to be in place.
    – Svante
    Commented Mar 7, 2010 at 1:27
  • 2
    In short: It does not work. There seems to be a simple solution. Will you implement it?
    – Svante
    Commented Mar 8, 2010 at 22:05
  • but you aren’t using the trunk version, right?. Last I looked, syntax highlighting support for VB was abysmal (i.e. non-existent) on Stack Overflow, and Prettify should actually be able to handle that. Commented Jul 27, 2010 at 11:38
  • Elisp actually seems to get hit hardest by '; see for example stackoverflow.com/questions/4189159/…. Also note that the above README mentions the need for an extension if you want it to handle lisp-like languages...
    – SamB
    Commented Nov 20, 2010 at 21:58
  • Note to time travelers and archeologists: my above comment refers to the README.html from r119. In case google breaks the link, that's also available via webcite.
    – SamB
    Commented Nov 20, 2010 at 22:19

Not the answer you're looking for? Browse other questions tagged .