Don't complain about the deprecated `kramdown.coderay` key when
`highlighter == "coderay"`, since that could have been set with the
legitimate `syntax_highlighter: coderay` setting. Instead, complain
only if the `kramdown.coderay` configuration setting is actually
present.
This removes the following warnings:
- /lib/jekyll/configuration.rb:151: warning: instance variable @default_config_file not initialized
- /lib/jekyll/converter.rb:12: warning: instance variable @highlighter_prefix not initialized
- /lib/jekyll/converter.rb:24: warning: instance variable @highlighter_suffix not initialized
- /lib/jekyll/converters/markdown.rb:9: warning: instance variable @setup not initialized
- /lib/jekyll/converters/markdown/kramdown_parser.rb:60: warning: instance variable @highlighter not initialized
- /lib/jekyll/frontmatter_defaults.rb:97: warning: shadowing outer local variable - path
- /lib/jekyll/plugin.rb:66: warning: instance variable @safe not initialized
- /lib/jekyll/regenerator.rb:147: warning: instance variable @disabled not initialized
- /test/test_convertible.rb:40: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_filters.rb:154: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_new_command.rb:84: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_site.rb:234: warning: assigned but unused variable - site
- /test/test_site.rb:240: warning: assigned but unused variable - site
- /test/test_site.rb:522: warning: assigned but unused variable - source
- /test/test_tags.rb:153: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:425: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:449: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:496: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:496: warning: instance variable @result not initialized
- /test/test_tags.rb:511: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:773: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_tags.rb:773: warning: instance variable @result not initialized
- /test/test_tags.rb:788: warning: ambiguous first argument; put parentheses or a space even after `/' operator
- /test/test_url.rb:66: warning: shadowing outer local variable - doc
- /lib/jekyll/url.rb:119:in `escape_path': warning: URI.escape is obsolete
- Pass &:to_sym as an argument to map instead of a block
- Pass &:capitalize as an argument to select instead of a block
- Pass &:to_s as an argument to map instead of a block
In the previous version, it would say 'redcarpet' wasn't installed,
due to the rescue LoadError block on line 93. This change will tell
the user that, in fact, rouge isn't installed and that this is the
cause of the error, not that redcarpet isn't installed.
Fixes#2464.
https://github.com/jekyll/jekyll/issues/2464
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.
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.
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.
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.
When using Ruby 1.8.7 and Kramdown 0.14.0 and newer, the following build error
would occur if any page in your site contained a `<name@example.com>` email
address link:
Generating... Conversion error: There was an error converting 'contribute.markdown'.
/Users/nick/Documents/puppet-docs/vendor/bundle/ruby/1.8/gems/kramdown-1.0.2/lib/kramdown/converter/html.rb:404:in `obfuscate': undefined method `encoding' for "mailto":String (NoMethodError)
See also:
http://rubyforge.org/tracker/index.php?func=detail&aid=29750&group_id=7403&atid=28673
This problem traced back to the following line in the Kramdown source:
result.force_encoding(text.encoding) if result.respond_to?(:force_encoding)
Strings aren't supposed to respond to the :force_encoding method in Ruby < 1.9,
but lib/jekyll/core_ext.rb was modifying the string class like so:
def force_encoding(enc)
self
end
Strings still won't respond to :encoding, though, so we get an error when
Kramdown tries to read the incoming encoding and everything will blow up.
An ack of the codebase suggests that this was only added so we could force an
encoding for rdiscount on 1.9 without having to check whether we were running
under 1.8. Since testing for said method to learn whether one is running under a
1.9-like encoding regime seems to be a thing in libraries we rely on, we
shouldn't insert this dummy method without also dummying every other part of the
Ruby 1.9+ encoding system.
This commit removes the dummy :force_encoding method to stop poisoning core
classes for libraries we use, and moves the adjustment for 1.9-like encoding
regimes to the one place where it's needed.
Pat Hawks
Edward Thomson
Parker Moore
Florian Thomas
Jordon Bedwell
Paul Robert Lloyd
Alfred Xing
Valery Tolstov
Ben Hanzl
Fabian Rodriguez
Robin Dupret
Eric Mill
Matthew Iversen
maul.esel
Matt Rogers
Nick Fagerlund