Support definition lists in Markdown

[murashitas]

No description provided.

[murashitas]

ごめんなさい！ 手元のリポジトリで行おうとしたのに、間違えて本家にPRを送ってしまいました……申し訳ありません……

[takahashim]

あー、でもMarkdownのdefinition list記法はサポートしてないので、これをmergeさせてもらった方がいいでしょうか？
（HTMLタグを生成するよりもMultiMarkdown・PHP Markdown ExtraとかのDL記法の方がスマートですが、GFMだとこの記法はサポートしてないんですよね…）

[murashitas]

これをmergeさせてもらった方がいいでしょうか？

可能であればそうしていただけるとありがたい（現在re:view→md2inaoみたいなのを個人的に実験しており、md2inaoにおいて定義リストはHTMLタグで表記しているため）……とは思うのですがが、↓の件でどのポリシーをとるかという話もありそうなので、「ぜひに！」というほどでもありません。

HTMLタグを生成するよりもMultiMarkdown・PHP Markdown ExtraとかのDL記法の方がスマートですが、GFMだとこの記法はサポートしてないんですよね…

このあたりのポリシーってあったりするのでしょうか？ たぶん以下くらいの選択肢がありそうですね。

1. GFMにないものはそもそもサポートしない
2. GFMにないがHTMLで表現できるものであればHTMLで表記する（=今回のPR）
3. GFMになくても、メジャーな拡張記法があればそれに変換する。メジャーな拡張記法がない場合はサポートしない
4. GFMになくても、メジャーな拡張記法があればそれに変換する。メジャーな拡張記法がない場合でもHTMLで表現できるものであればHTMLで表記する

※「GFM」は「CommonMark」かも？

上述の実験の件とは関係なく、個人的には2推しではあります！

[takahashim]

Markdownビルダーについてのポリシーは現状はっきりとは決まっていないので、作りながら考える方向に今はなっています。
原則としては、他のビルダーで共通して使える記法はMarkdownビルダでも使えて然るべきかと思うので、実装はした方がよいかと思います。が、場合によっては、

• 複数のビルダにわける（MarkdownBuilderとGFMBuilderとか）
• config.ymlでどの拡張記法をサポートするかを指定できるようにする

といった対応もありえます。

あと、CommonMarkについては今のところ意識する必要はないかと思います。Re:VIEWはポリシーとして現場で動く・役に立つことを大事にしているため、まだ提案段階の仕様でしかないCommonMarkよりも、すでにあって使っているMarkdown処理系を利用するにあたって困ること・困ったことを解決する方向で考えるべきでしょう。

[murashitas]

詳しく説明いただきありがとうございます！ ↓がポイントなのですね。

すでにあって使っているMarkdown処理系を利用するにあたって困ること・困ったことを解決する方向で考えるべきでしょう。

今回のPRを取り込んでいただいても問題なさそうで、よかったです。よろしくお願いします 🙏

[takahashim]

とりあえず現状ではMarkdownビルダーでエラーが出ることは確認できたので、マージしますね