inline <style> element results in parse error

[faithanalog]

example markdown contents:

a

<style>

  img.grid2 {
    width: 370px;
    height: auto;
  }
  img.grid3 {
    width: 244px;
    height: auto;
  }
  img.grid2 + img.grid2 {
    margin-left: 4px;
  }
  img.grid3 + img.grid3 {
    margin-left: 4px;
  }

</style>

hello

error:

lua: .../vi/.luarocks/share/lua/5.4/lunamark/reader/markdown.lua:196: parse_blocks failed on:
a

<style>

  im
stack traceback:
	[C]: in function 'error'
	.../vi/.luarocks/share/lua/5.4/lunamark/reader/markdown.lua:196: in upvalue 'parse_blocks'
	.../vi/.luarocks/share/lua/5.4/lunamark/reader/markdown.lua:1193: in upvalue 'md_to_html'

version info:

> luarocks --local --lua-version 5.4 show lunamark

lunamark 0.5.0-1 - General markup format converter using lpeg.

[Omikhleia]

Running with the latest master (as 0.5.0-1 starts being fairly old), I didn't observe any error, but this being said, the output doesn't seem to meet the expectations...

The <style> tag not a registered as a block element, and is therefore considered as an inline element (so doesn't accept blank lines, and processes anything looking as markdown inside it).
It seems to me it should have been a block element (as <script> is, for instance, and thus be added here:

lunamark/lunamark/reader/markdown.lua

Lines 436 to 454 in ae3091a

	parsers.block_keyword =
	parsers.keyword_exact("address") + parsers.keyword_exact("blockquote") +
	parsers.keyword_exact("center") + parsers.keyword_exact("del") +
	parsers.keyword_exact("dir") + parsers.keyword_exact("div") +
	parsers.keyword_exact("p") + parsers.keyword_exact("pre") +
	parsers.keyword_exact("li") + parsers.keyword_exact("ol") +
	parsers.keyword_exact("ul") + parsers.keyword_exact("dl") +
	parsers.keyword_exact("dd") + parsers.keyword_exact("form") +
	parsers.keyword_exact("fieldset") + parsers.keyword_exact("isindex") +
	parsers.keyword_exact("ins") + parsers.keyword_exact("menu") +
	parsers.keyword_exact("noframes") + parsers.keyword_exact("frameset") +
	parsers.keyword_exact("h1") + parsers.keyword_exact("h2") +
	parsers.keyword_exact("h3") + parsers.keyword_exact("h4") +
	parsers.keyword_exact("h5") + parsers.keyword_exact("h6") +
	parsers.keyword_exact("hr") + parsers.keyword_exact("script") +
	parsers.keyword_exact("noscript") + parsers.keyword_exact("table") +
	parsers.keyword_exact("tbody") + parsers.keyword_exact("tfoot") +
	parsers.keyword_exact("thead") + parsers.keyword_exact("th") +
	parsers.keyword_exact("td") + parsers.keyword_exact("tr")

(The HTML standard allows <style> to occur in the body of a document (though having in it head is recommended), so it seems supporting it is probably legit.)

[Omikhleia]

BTW, is the above analysis is approved by the maintainers, it's one line fix... With it and the few current pending PR, and possibly another one (e.g. I could propose a backport of what I did in my vendored copy for #50), perhaps it could be the nice time for having a 0.6.0 release?

[faithanalog]

I think my original problem was related to DOS line-endings fwiw. I need to go try to reproduce it again, but I'm not having problems right now. but it's also true what you wrote about the <style> element, I am working around that in other ways