syncronising with "Jekyll style "do not show or parse"" concept in commonmark talks

[mofosyne]

I would like to at least synchronize the concept in http://talk.commonmark.org/t/jekyll-style-do-not-show-or-parse-sections/918 with grey-matter. E.g. change bits of gray-matter or "jekyll style non parse block" to better match each other.

The objective of "jekyll style do not parse", is to inform commonmark of what section to ignore, since it was determined though discussion that metadata handling is better performed by an external program (like grey-matter ).

Some of the things that differs between them is:

More than just front matter metadata.

The non parse block can occur in more places than just the top via these two forms:

---
CONTENT WITHOUT ANY NEW LINE INBETWEEN
E.G. YAML OR JSON CONTENT

---

:---

Multiline Non parsed content

:---

optional stylized boxes

--------- yaml --------
YAML: INSERT YAML HERE
-----------------------

optional descriptive field

--- yaml: slide01 ---
CSS: style.css

---

---

Discussion

Is there any issue with adding this form, for both grey-matter and "non parse block"? (A space is added).

--- yaml
CSS: style.css

---

[ghost]

About non parse block

Well, why should gray-matter do such heavy work? If CommonMarks parsers can ignore those special content, why not let the parser extract them for you?

The most obvious advantage of using front-matter is we don't have to parse every line of the file, right?

About stylized/descriptive box

I don't know why @jonschlinkert change the type of delims from Array to String, if it was still Array, it could contain String or RegExp, then you could use regexes to match indefinite delimiters.

[jonschlinkert]

sorry it has taken me so long to get back to you on this @mofosyne.

I did some refactoring to try to make it easier to accomplish this kind of thing, but haven't pushed it up yet b/c I'm not sure about the best approach yet.

Honestly my #1 goal with speed with this lib (without sacrificing some of the really useful features). When building a blog or website that has hundreds of pages, parsing front matter is probably one of the biggest noticeable drags on build time.

change bits of gray-matter or "jekyll style non parse block" to better match each other.

IMHO, using something like :--- is a great solution for this. I don't think we need anything more complicated to do the job. We can easily add a flag/option to change the delimiters from --- to :--- and still allow a language to be defined on the blocks (e.g. :---yaml) so that parsers like gray-matter can extract data from the blocks.

As a side-note, you made a comment about not having any newlines in metadata, I'm not sure why that's necessary. IMO the delimiters are enough to ensure that you're actually parsing a block of metadata, and whitespace sensitivity is left to be decided by the language used for parsing it.

I don't know why @jonschlinkert change the type of delims from Array to String

Yeah, I've thought a lot about that. I made the change b/c I didn't have any good use cases where the opening and closing delimiter shouldn't be the same. This lib does not parse with regex, which is why it's so fast.

I can easily add the array style delimiters back, and even allowing regex for the delimiters, I guess more discussion about goals would help.

[ghost]

I'm maintaining the gulp-gray-matter plugin, so I think that breaking change is somewhat unnecessary for that speed-up. (I can fork this simple tool and transfer that project to others though…) I don't need regex, but I hope you bring the old style back.

[jonschlinkert]

I can fork this simple tool and transfer that project to others though

Go for it. mentioning that you can fork the project probably won't inspire me to want to help you anytime soon. It might inspire me to create a better gulp plugin for front matter though.

[ghost]

Okay, if you want to take the name “gulp-gray-matter” from NPM, call me anytime. I'm not threatening you. Just tired of dealing with the breaking changes for everyone. I don't really care about using regexes or arrays for that matter (My text in parentheses is so amazing? I just mean you can take my project with regard to “gray-matter”.). Thanks for your good work anyway.

[jonschlinkert]

I pushed up a new release that adds back support for multiple delimiters (and was able to do so while increasing speed substantially).

Just tired of dealing with the breaking changes for everyone.

this is why semver exists. you shouldn't have breaking changes unless you choose to.

I don't really care about using regexes or arrays for that matter

as a plugin author I think you should care if you look at the benchmarks. doing this with regex is awful for users. It's most obvious when you're building a big site. parsing front-matter can be the biggest drag of an entire build if every single post/page is being parsed.

[ghost]

Thanks. I'm not a native English speaker so my words are sometimes obscure. :-|

I meant I don't care adding those new features if it would not slow down a lot without using them.

Anyway, I'll do some benchmarks to see if there is a good way to keep your preferred parsing method unaffected, so that I can prove it is not necessary to remove the old features.

[jonschlinkert]

no worries, I see what you mean now.

so that I can prove it is not necessary to remove the old features.

I already added the feature back, as you requested. and it's faster now than it was before that. I'm glad I went down this path. anyway we should probably open a new issue if we want to discuss further since this is ot

[jonschlinkert]

closing due to age