Supporting more kramdown options. #1201

zachgersh · 2013-06-10T04:47:37Z

Getting the conversation started on #1095. Taking @parkr's suggestion.

zachgersh · 2013-06-11T18:07:37Z

@mattr- @parkr for review. I actually am assuming I should add some of the other kramdown options as tests? Additionally, this would probably require a docs update?

mikegreiling · 2013-06-19T08:41:26Z

👍

zachgersh · 2013-06-28T17:30:12Z

I am hoping you guys get some discussion in on this soon @parkr and @mattr-.

Unsure if anything else would actually be needed here.

mattr- · 2013-06-28T17:35:44Z

lib/jekyll/core_ext.rb

+
+  def symbolize_keys!
+    keys.each do |key|
+      self[(key.to_sym rescue key) || key] = delete(key)


What strange Ruby creature is this?

Stolen as per @parkr's suggestion on #1095 :)

Ripped from Rails core extensions. There's a note in my comment in #1095 :)

zachgersh · 2013-06-28T18:19:50Z

So, the more you stare at the function the more awesome it becomes. The magic comes from delete(key) because it actually returns the value of what it deletes. So, returning the value from what we delete now sets the symbolized key to that value!

BRILLIANT!

mattr- · 2013-06-28T19:28:50Z

An additional test to verify passthrough of additional options plus a doc update would be nice to have here.

zachgersh · 2013-06-28T23:07:48Z

Agreed,

Here's the issue I have though. For my test do I need to pass every single possible kramdown item in the hash? We allow all of them so it only seems right. What do you think @mattr-?

mattr- · 2013-06-29T00:24:28Z

I don't think we need every possible option. Ultimately, we just need to verify the they're in the hash properly. It's kramdown's responsibility to handle its own options.

On Fri, Jun 28, 2013 at 6:07 PM, Zach notifications@github.com wrote:

Agreed,

Here's the issue I have though. For my test do I need to pass every single possible kramdown item in the hash? We allow all of them so it only seems right. What do you think @mattr-?

Reply to this email directly or view it on GitHub:
#1201 (comment)

zachgersh · 2013-06-30T17:32:21Z

sure thing @mattr- I will add a test today. @parkr any thoughts?

maul-esel · 2013-06-30T18:34:11Z

lib/jekyll/converters/markdown/kramdown_parser.rb

@@ -26,7 +26,7 @@ def convert(content)
            # not using coderay
            base_kramdown_configs
          end
-          Kramdown::Document.new(content, kramdown_configs).to_html
+          Kramdown::Document.new(content, @config["kramdown"].symbolize_keys).to_html


You could delete all the other code in that method and the base_kramdown_configs method then, couldn't you?

Looking at it again, will this work with the nested config hash (coderay) ?

Yeah, it'd have to deep-symbolize if that is needed.

Hm, where are coderay options used in kramdown? http://kramdown.rubyforge.org/options.html

Hm, where are coderay options used in kramdown?

❓ Kramdown wants the coderay options directly in its option hash (with symbol keys, of course), but jekyll seems to have historically chosen to have them in a nested coderay hash in _config.yml.

I was wondering where in the Kramdown documentation these Coderay options are mentioned and why Kramdown wants them in their array of options.

where in the Kramdown documentation these Coderay options are mentioned

On the site you linked, starting from option 3, coderay_bold_every.

I don't know Kramdown but it seems like another code highlighting system:

enable_coderay
Use coderay for syntax highlighting

I'm literally blind. Sorry about that :)

zachgersh · 2013-07-01T00:18:47Z

So,

Here is what I am going to do gents:

I am going to write a couple of tests (symbolizing the keys and having coderay be part of the options hash)
I am going to go ahead and remove the base_kramdown_configs methods
I am going to make coderay part of the kramdown options hash

Then I will run the test suite (lol @ my spelling mistake) again to see if anything has broken.

Sound good?

parkr · 2013-07-01T09:06:24Z

Sounds good to me. Thanks!

mattr- · 2013-07-01T14:49:30Z

Yup. 👍

parkr · 2013-07-12T16:31:14Z

@zachgersh I'd love to include this in the v1.1 release if you have time today or tomorrow to finish this up?

zachgersh · 2013-07-12T17:47:55Z

I will have this done for you tomorrow! Apologies for the delay.

On Jul 12, 2013, at 11:31 AM, Parker Moore notifications@github.com wrote:

@zachgersh I'd love to include this in the v1.1 release if you have time today or tomorrow to finish this up?

—
Reply to this email directly or view it on GitHub.

parkr · 2013-07-12T18:39:44Z

No problem! :D

parkr · 2013-07-13T14:36:34Z

@zachgersh Wait, why are we removing the base_kramdown_configs method?? I like to see those things separate - easier reading usually :)

zachgersh · 2013-07-13T14:40:03Z

Okay. I will leave it in.

On Jul 13, 2013, at 9:36 AM, Parker Moore notifications@github.com wrote:

@zachgersh Wait, why are we removing the base_kramdown_configs method?? I like to see those things separate - easier reading usually :)

—
Reply to this email directly or view it on GitHub.

parkr · 2013-07-13T14:44:11Z

If it's poor organizing then we can move thing around but if not, it would be wonderful if you left it in. Thank you!! ❤️

maul-esel · 2013-07-13T19:07:10Z

It seems it is not used anymore in the code for this PR, that's why I had suggested so.

maul-esel · 2013-07-13T19:08:16Z

I mean, it's called twice, but the result (kramdown_configs) is discarded anyway.

zachgersh · 2013-07-13T19:29:24Z

Hey @maul-esel could you jump in the irc channel? I actually wanted to run a test by you. I discarded it without ill effect including the coderay bit as well.

parkr · 2013-07-13T19:43:48Z

@maul-esel If it's not used then we don't need it, ya! But we need to keep the current configuration options absolutely the same (in terms of coderay, etc) so we'll need at least the coderay stuff,.

zachgersh · 2013-07-13T19:47:56Z

@parkr IRC please :)

zachgersh · 2013-07-13T21:00:04Z

Hey @mattr- and @parkr, I am having some issues actually trying to test this properly.

Also I found that we are already testing kramdown options here:

https://github.com/mojombo/jekyll/blob/master/test/test_kramdown.rb

So what I decided on was deep_merging in a new option in:

remove_span_html_tags

Then I try to run this sort of test

assert_match /<\/p>/, markdown.convert(%{''}).strip

I was hoping that the kramdown would strip the  and then return just empty  tags. It doesn't do that and I am pretty sure the options get through but something is a bit strange.

If one of you is around on IRC tonight I think I could wrap this up fairly quickly but I need some help.

mattr- · 2013-07-14T02:45:34Z

Sorry, I missed this. I'm not usually around IRC until 9pm Central Time or so, which is usually sometime early morning for all y'all. 😀

mattr- · 2013-07-14T04:56:20Z

I 👍 this for the code, but I 😡 at @zachgersh's choice of options to test. the remove_span_html_tags option only works with a different Kramdown converter than the HTML converter. Win some, lose some. 😄

zachgersh · 2013-07-14T05:20:31Z

Looking at this, there really aren't many more options to test:

http://kramdown.rubyforge.org/converter/html.html

Our original test was already pretty good :)

I am about to commit a few slight changes to this.

…s we don't support.

Supporting more kramdown options.

parkr · 2013-07-14T15:47:06Z

lib/jekyll/converters/markdown/kramdown_parser.rb

@@ -13,7 +13,7 @@ def initialize(config)

        def convert(content)
          # Check for use of coderay
-          kramdown_configs = if @config['kramdown']['use_coderay']
+          if @config['kramdown']['use_coderay']
            base_kramdown_configs.merge({


Whoops, forgot a call to the method

mattr- · 2013-07-15T17:11:53Z

Gasp! I'm not 😡 at @zachgersh's choice of option, but rather at Kramdown's weird implementation of stripping HTML tags from documents and the fact that the option doesn't work with the HTML converter it provides. Sorry @zachgersh 😭

mattr- reviewed Jun 28, 2013
View reviewed changes

maul-esel reviewed Jun 30, 2013
View reviewed changes

zachgersh added 2 commits July 14, 2013 00:24

Supporting more kramdown options.

774bf07

Deleted unused code.

90500f3

Added a configuration warning to our docs for the two kramdown option…

b0fbfdb

…s we don't support.

parkr added a commit that referenced this pull request Jul 14, 2013

Merge pull request #1201 from zachgersh/all_kramdown

4ce89ac

Supporting more kramdown options.

parkr merged commit 4ce89ac into jekyll:master Jul 14, 2013

parkr reviewed Jul 14, 2013
View reviewed changes

parkr added a commit that referenced this pull request Jul 14, 2013

Update history to reflect merge of #1201.

db0be23

parkr added a commit that referenced this pull request Jul 14, 2013

Fix for kramdown coderay options. #1201.

e95086b

parkr added a commit that referenced this pull request Jul 14, 2013

merge bang to modify in place. Woops. #1201

5d91b8f

parkr mentioned this pull request Jul 14, 2013

Only some kramdown options are supported #1095

Closed

jekyll locked and limited conversation to collaborators Feb 27, 2017

jekyllbot added the frozen-due-to-age label Feb 27, 2017

Supporting more kramdown options. #1201

Supporting more kramdown options. #1201

Conversation

zachgersh commented Jun 10, 2013

zachgersh commented Jun 11, 2013

mikegreiling commented Jun 19, 2013

zachgersh commented Jun 28, 2013

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zachgersh commented Jun 28, 2013

mattr- commented Jun 28, 2013

zachgersh commented Jun 28, 2013

mattr- commented Jun 29, 2013

Here's the issue I have though. For my test do I need to pass every single possible kramdown item in the hash? We allow all of them so it only seems right. What do you think @mattr-?

zachgersh commented Jun 30, 2013

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zachgersh commented Jul 1, 2013

parkr commented Jul 1, 2013

mattr- commented Jul 1, 2013

parkr commented Jul 12, 2013

zachgersh commented Jul 12, 2013

parkr commented Jul 12, 2013

parkr commented Jul 13, 2013

zachgersh commented Jul 13, 2013

parkr commented Jul 13, 2013

maul-esel commented Jul 13, 2013

maul-esel commented Jul 13, 2013

zachgersh commented Jul 13, 2013

parkr commented Jul 13, 2013

zachgersh commented Jul 13, 2013

zachgersh commented Jul 13, 2013

mattr- commented Jul 14, 2013

mattr- commented Jul 14, 2013

zachgersh commented Jul 14, 2013

Choose a reason for hiding this comment

mattr- commented Jul 15, 2013