My local environment isn’t compiling my Jekyll site with the correct markup for Rouge syntax highlighting. So for something like
{% highlight javascript %}
<script>
JavaScript code goes here
</script>
{% endhighlight %}
the markup I get after building is
<code class="language-javascript" data-lang="javascript">
"<script>
JavaScript code goes here
</script>"
</code>
Instead of
<code class="language-javascript" data-lang="javascript">
<span class="o"> < </span>
<span class="nx"> script </span>
<span class="o"> > </span>
<span class="nx"> JavaScript code goes here </span>
<span class="o"> < </span>
<span class="sr"> /script </span>
<span class="o"> > </span>
</code>
I have ruby 2.6.5p114 installed on my mac with jekyll 4.0.0 and
% rougify -v
confirms I have version 3.14.0 installed.
I get the same behaviour with my custom built theme and with a fresh blank jekyll site.
I’ve tried various setting in the _config;
kramdown:
input: GFM
syntax_highlighter: rouge
and
highlighter: rouge
I’m familiar with Jekyll but NOT Ruby so Im a little stuck on how to trouble shoot this.
Since you have GFM have you tried using the three backtick method instead of Jekyll’s {% highlight %} tag?
```javascript
<script>
JavaScript code goes here
</script>
`` `
hmm, that method generates token markup but different to standardised Rouge tokens.
So,
```javascript
<script>
JavaScript code goes here
</script>
Compiles to,
<code class=" language-javascript">
<span class="token operator"> < </span>
script
<span class="token operator"> > </span>
JavaScript code goes here
<span class="token operator"> > </span>
<span class="token operator">/</span>
script
<span class="token operator"> > </span>
</code>
Running,
% rougify someFileContainingMarkup.md
returns highlighted results so I think that indicates my local env is correct in regards to Rouge.
But still, % jekyll s returns results that either contain incompatible/incomplete token markup or no token markup.
The same when compiled on GitHub returns Rouge token markup, so it must be something local to me.
ie,
<code class="language-javascript" data-lang="javascript"
<span class="o"> < </span>
<span class="nx">script</span>
<span class="o"> > </span>
<span class="nx">JavaScript</span>
<span class="nx">code</span>
<span class="nx">goes</span>
<span class="nx">here</span>
<span class="o"> < </span>
<span class="sr">/script> </span>
</code>
The tokens aren’t what you want because you’re using the wrong lexer I think.
It’s Javascript, but it’s inside a script tag. So what you want is html as the language. If you want to do straight Javascript then remove the wrapping <script> elements.
{% highlight html %}
<script>
JavaScript code goes here
</script>
{% endhighlight %}
{% highlight javascript %}
JavaScript code goes here
{% endhighlight %}
The Rouge site might be helpful to test out different languages and see how it applies the various tokens to your code.
http://rouge.jneen.net/
Thanks for the feedback @mmistakes. Having declared the correct language, I still get markup that is based on the long name classes. So my local env gives <span class="token keyword">var</span> whereas the GitHub Pages version uses the short name class, ie <span class="kd">var</span>
I’ve lost track of all the things I have tried. Some are, removed and reinstalled Jekyll and Rouge. Set my Gemfile to use only the github-pages gem (vs 203) and various kramdown settings in my _config.
I feel like there is some basic nomenclature I’m missing because all my googling ends up with case examples where the classes being generated are the short name versions. I’m reluctant to just write a style file based on the long name classes because it would be a fix for an issue that I don’t really understand. maybe if I’m still in the same boat in a week I might think different!!!
For what it’s worth I use the short name classes in my style sheets for all Jekyll themes I release. The fact that you’re getting long names locally tells me it’s either a Kramdown setting or different gem version of either Jekyll, Kramdown, or Rouge from what GH pages used.
Have you checked your Kramdown settings against the ones GH uses?
Jekyll’s highlight tag does produce different markup from GFM triple backtick code blocks too.
OK this is getting silly, I’ve unistalled all but my system ruby. Reinstalled rbenv, ruby 2.6.5 and Jekyll 4.0.0. Same markup as before. Dug a little in the gems but couldn’t see any indication of the class names being generated. Then tried lineson and …
{% highlight css linenos %}
.class{
width: 100px
}
{% endhighlight %}
Produces the following html,
<div class="language-css highlighter-rouge">
<div class="highlight">
<pre class="highlight language-css">
<code class=" language-css">
<span class="token selector">
1
2
3
.class
</span>
<span class="token punctuation">
{
</span>
<span class="token property">
width
</span>
<span class="token punctuation">
:
</span>
100px
<span class="token punctuation">
}
</span>
</code>
</pre>
</div>
</div>
which renders to ,
1
2
3
.class{
width: 100px
}
This is perhaps the most mind-boggling issue I may have come across till date.
You’re using {% highlight %} which should renders the following at minimum:
<figure class="highlight">
<pre>
<code class="language-<LANG>" data-lang="<LANG>">
But in your case,
<div class="language-css highlighter-rouge">
<div class="highlight">
<pre class="highlight language-css">
<code class=" language-css">
is similar to markup generated by kramdown’s fenced code block:
<div class="language-<LANG> highlighter-rouge">
<div class="highlight">
<pre class="highlight">
<code>
The difference here is just the addition of " language-css" to both <pre> and <code>
My guess is that perhaps you may have toyed around with either kramdown or rouge and configured your system to always use that version…
What does your bundle config say?
Is it configured to always point to a certain git repository on your system instead of the installed rubygem…?
I haven’t knowingly changed any gems. In fact, yesterday I uninstall every thing but my system ruby and reinstalled with rbenv again. I’ve tried using both fence block and liquid tags. There does seem to be a difference but neither produce the kind of markup I’m expecting (ie compatible shorname classes). I even got to the point where I became suspicious of my Python env to removed that and reinstalled it in the off chance that rouge/kramdown was sending something to some Pygment script.
% bundle config
Settings are listed in order of priority. The top value will be used.
gem.test
Set for the current user (/Users/arrancurran/.bundle/config): "rspec"
gem.mit
Set for the current user (/Users/arrancurran/.bundle/config): true
gem.coc
Set for the current user (/Users/arrancurran/.bundle/config): true
Was this issue ever solved? I’m having a very similar issue, and I’m interested in reading about a possible solution.