Allow indication of language for code blocks (esp. inline)

[netcarver]

It would be useful to allow some kind of language markup on code blocks to better support syntax highlighting.

bc. and bc.. already support class, id, style and language attributes but inline code @...@ has no support for any of these. In addition, the W3 spec suggest the use of classes named after the programming language but prefixed with "language-" be used on the <code> elements.

Currently typing...

bc(php). echo ...

...into textile would lead to...

<pre class="php"><code>echo...

...which doesn't follow this suggestion. In keeping with textile's aim of trying to reduce keystrokes, perhaps we need a new convention for 'language tagging' of code blocks.

Should we override the use of the existing language attribute marker for code blocks or do something different again? Ideas anyone?

[gocom]

Unless the code block is in different language? But, yep, that would look fine.

The issue with the raw class isn't typing, but the fact that you can't use it in strict mode. So there should be something like this.

In TXP.com forum code we extended Textile and used the first line for the language identifier GitHub style, but if we can get an actual attribute to Textile that can handle that, then more the merrier.

The language attribute should be fine, I believe. Altho, it will remove the ability to use language for code blocks.

[netcarver]

@gocom Your comment and linked example triggers various thoughts...

• Given that the language marker is used to represent the language in the containing element; I think that, for code blocks, it doesn't have to represent the human language that the contained code emits in it's output/print/echo statements, just that of the programming language used in the block.
• That under html5 output we can combine the class and language markers to wit: bc(prettyprint)[php]. echo... but it isn't very pretty. So...
• ...we could add something like public function setCodeClass($class) that automatically applies a common class to all code blocks OR ...
• ...that a code-block language marking feature would be a good Textile plugin candidate - and not a core feature.
• That we should definitely delay implementing this till after the 2.5 branch is feature frozen.

[netcarver]

Ah, strict mode. Ok that kills combination with classes anyway so we'd have to allow a very limited [lang] marker into strict mode if we did go with this idea.

[netcarver]

I got my example above slightly wrong. The W3 spec says it is to go on the code element while I showed it on the pre element. So...

bc[php]. echo "Hello world!";

...would give...

<pre><code class="language-php">echo...

...if we follow the spec (which is merely a suggestion anyway.) Doing it like this isn't going to be compatible with every syntax highlighter so we should either reserve it in Textile's syntax but hand the implementation off to a plugin subsystem or close the issue.

[philwareham]

It would be really handy to revisit this issue and allow for classnames to be applied to the inner code tag. Basically using Textile with a highlighter such as Prism is not possible right now.

Don't hardcode it to use any predefined language-* prefix either - let the user decide this.

So, as an example, using:

bc(line-numbers)[language-markup]. some code

Would render:

<pre class="line-numbers"><code class="language-markup">some code</code></pre>

[netcarver]

@philwareham Just pushed a test branch that has this feature in it. Please try out the issue-96 branch and let me know if it does what you need.

[philwareham]

@netcarver works great for me, thanks!

[netcarver]

@philwareham Thanks for testing. Do you anticipate any call for this on inline code elements?

[philwareham]

I guess it's always good to have the option available for inline too, if it's not too much trouble to implement.

[netcarver]

Looking at the source for handling the inline code spans - I'm inclined to leave it to a later version unless there is demand for it.

[philwareham]

No worries. It's edge case stuff really.

[netcarver]

I've added the "Breaks backwards compatibility" label as this change will cause a small variation in the generated output if anyone happens to be using the language attributes on a block code element.