Support for fenced code block info string

[arobase-che]

Hi,

I'm looking for a support for fenced code block info string. It's not a regular markdown but it's pretty commun and both GFM and CommonMark spec it.

If i implement it and make a pull request, will it be merged or should i make a plugin ?

Thanks ! 😉

[ChristianMurphy]

Since it is part of the common mark spec, I'd personally lean toward including this in remark directly.

---

It'd be good to get the specification example as a test

~~~~    ruby startline=3 $%@#$
def foo(x)
  return 3
end
~~~~~~~

https://spec.commonmark.org/0.28/#example-112

---

and also would be good to get the MDAST spec updated with the new attribute
https://github.com/syntax-tree/mdast#code

[arobase-che]

Arf, in fact ... While discussing with @Hypercubed he remarked to me that the info string is the whole string. In you example "ruby starline=3 $%@#$". Which is exactly the value of the "lang" attribute.

So "lang" is actually the info string. Now "lang" is the info string, but it's used by other plugins as the first word of the info string as it's name suggests it is.

I will make a PR soon fix it.

Edit: Missed the 'd' >_<

[Hypercubed]

The name is @Hypercubed... :)

Anyway, yeah, from the CommonMark spec:

The content of a code fence is treated as literal text, not parsed as inlines. The first word of the info string is typically used to specify the language of the code sample, and rendered in the class attribute of the code tag. However, this spec does not mandate any particular treatment of the info string.

So, if you want to keep backward compat, the "info string" should be the whole string and lang should be the first word of the info string. This might be breaking for existing code that looks for the full info string in lang... (it will break me, but for the greater good?).

[wooorm]

@Hypercubed Yeah I was thinking something along those lines, a code.infoString being the whole thing, lang being the first “word”? It’s breaking, but more fixing.

@arobase-che Thanks for the issue! Sorry for the slow response. I’m also happy to see how you worked “remark” in your comment (“...he remarked to me...”) 😛

[arobase-che]

needs pr you said ?

Ok let's go. Where are the tests about remark-parse ? I only found that file.

[ChristianMurphy]

There are also fixtures https://github.com/remarkjs/remark/tree/02297a5dea290751a0bfd766b4154ad403307b7e/test/fixtures
Each text file in input/ has a matching JSON file in tree/.

[arobase-che]

Ty 👍

---

05:30:55  ~/g/r/t/fixtures/tree  grep -rw '"lang"' | wc -l
853

Oups ! That's a lot of files >_<
Should i add the "infoString" attribute along with the "lang" one ?

If yes, will finish by the day.

[ChristianMurphy]

yes, lang and infoString 👍

---

It would also help to document the new attribute at https://github.com/syntax-tree/mdast/blob/master/readme.md#code

[wooorm]

@arobase-che You can run node script/regenerate-fixtures to regenerate all output trees, you don‘t have to do that manually!

So you can write the code, add an input/ fixture, create a corresponding tree/ one (contents has to be json but otherwise doesn’t matter), and run regenerate-fixtures. You can then check with git diff what changes are made to all the fixtures with the new algorithm!

[arobase-che]

Ty @wooorm

I still on it.