Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for the Rouge syntax highlighter #1859

Merged
merged 9 commits into from
Dec 31, 2013
Merged

Conversation

robin850
Copy link
Contributor

Hello,

This is another shot at #930 since the Jekyll repository has moved since the opening of the latter. So this pull request adds support for the Rouge syntax highlighter which is a nice alternative to Pygments.

Here is the work done on this patch:

  • Improve the testing of the highlight tag when Pygments is enabled.
  • Rename the pygments configuration option to highlighter to easily add new highlighters in the future
  • Add support for Rouge
  • Update the documentation to match these changes

Let me know if I should change anything else.

Have a nice day.

Previously, the assertion made wasn't enough to check whether the code
block was correctly parsed through Pygments (and it was not the case).
This commit simply ensure there is a div with the "highlight" class and
fix the test to correctly invoke the Liquid tag rendering.
Rename the pygments configuration option to highlighter to allow
different highlighters in the future. For now, the allowed values are
`pygments` and `null`.

It's now more straightforward to plug another syntax highlighter.
@robin850
Copy link
Contributor Author

@jayferd : I've added some more commits ; thanks for the quick feedback! ❤️

@@ -362,7 +362,7 @@ Jekyll handles two special Redcarpet extensions:
# ...ruby code
```

With both fenced code blocks and pygments enabled, this will statically highlight the code; without pygments, it will add a `class="LANGUAGE"` attribute to the `<code>` element, which can be used as a hint by various JavaScript code highlighting libraries.
With both fenced code blocks an highlighter enabled, this will statically highlight the code; without any syntax highlighter, it will add a `class="LANGUAGE"` attribute to the `<code>` element, which can be used as a hint by various JavaScript code highlighting libraries.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lost a "d" here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch thank you!

By setting the `highlighter` setting to `rouge` you can now easily
highlight your code with it instead of relying on Pygments. However,
Jekyll doesn't depend on Rouge explicitly, you will need to install it
or add it to your Gemfile.

The documentation has been updated accordingly.
In case you are upgrading from 1.4.2 to 2.0 and the pygments option is
set to true, then the highlighter option will be set to pygments
automatically.
To avoid code duplication and have to keep tracking of the API change of
Rouge, let's rely on the Redcarpet plugin and customize the output on
our needs.
@parkr
Copy link
Member

parkr commented Dec 22, 2013

Whoa, this is a lot. I'll go through it and try to give my thoughts. In the future, please submit just one PR per eventual line in History.markdown and please let us update History.markdown (it's part of the PR merge process for us).

Given I have an "index.html" file that contains "{% highlight ruby %} puts 'Hello world!' {% endhighlight %}"
And I have a configuration file with "pygments" set to "true"
Given I have an "index.html" page that contains "{% highlight ruby %} puts 'Hello world!' {% endhighlight %}"
And I have a configuration file with "highlighter" set to "pygments"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should make sure it works without this line, depending upon the default. If it's not set, to which should it default?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually you are right ; this line is not needed since this parameter should default to pygments. I think we can simply remove it.

@parkr
Copy link
Member

parkr commented Dec 22, 2013

This LGTM besides my comments.

Since Rouge yields the pre tag with a class attribute but we don't want
it, we should set the wrap parameter to false when instantiating a new
formatter object.

Also use Rouge::Formatter#format instead of #render which is deprecated
and will be removed in the near future.
Since the highlighter configuration option should default to pygments,
we don't have to explicitly set it in the step testing the output with
pygments.
@robin850
Copy link
Contributor Author

Whoa, this is a lot. I'll go through it and try to give my thoughts. In the future, please submit just one PR per eventual line in History.markdown and please let us update History.markdown (it's part of the PR merge process for us).

Really sorry ; I will next time! 😢

I've updated my branch with your comments. Thank you!

@parkr
Copy link
Member

parkr commented Dec 24, 2013

Really sorry ; I will next time! 😢

No problem, just an FYI for the future. It makes it way easier for @mattr- and I to review but this isn't anything we can't handle. Your contribution is incredibly valuable to us so I appreciate it either way 😃

I've updated my branch with your comments. Thank you!

Brilliant! It all looks good to me. Will just want @mattr-'s 👀 on this and we'll be 👍 to 🚢.

Rouge 1.3.0 introduced a `rouge_formatter` helper which is handy to
overwrite the formatter default when using the Redcarpet plugin so let's
require this version at the very least.

An abort statement will be thrown when the installed version is not
correct.
@ghost ghost assigned mattr- Dec 26, 2013
@siong1987
Copy link

👍

@mattr-
Copy link
Member

mattr- commented Dec 31, 2013

I merged another PR and this won't merge cleanly now. Could you rebase it against current master? Thanks!

@parkr
Copy link
Member

parkr commented Dec 31, 2013

Conflict is only in History.markdown, should be a simple fix, @robin850. Thanks!

@mattr-
Copy link
Member

mattr- commented Dec 31, 2013

oh, well, in that case, uno momento.

@parkr
Copy link
Member

parkr commented Dec 31, 2013

You ok @mattr-? It's been 12 minutes 😜

@mattr-
Copy link
Member

mattr- commented Dec 31, 2013

hey! these manual merges take time! i don't have automated script to do these yet 😝

mattr- added a commit that referenced this pull request Dec 31, 2013
@mattr- mattr- merged commit 036cbda into jekyll:master Dec 31, 2013
@parkr
Copy link
Member

parkr commented Dec 31, 2013

😉 Thanks for taking care of it ❤️

@jneen
Copy link

jneen commented Dec 31, 2013

:D

@robin850
Copy link
Contributor Author

Thank you guys and happy new year! ❤️ 💙 💛 💜 💚

@ghost ghost mentioned this pull request Feb 1, 2014
@jekyll jekyll locked and limited conversation to collaborators Feb 27, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants