本日の知見未満。
以前、というか数日前に外出中に調べていて、その辺りをまとめるのをすっかり忘れていた話。
まあ、 Markdown で 電子書籍 が作れる！ という ソフトウェア に、
っていうのが有るんですが、この GitBook の Markdown 処理系は、 ( 2015-11-30 ) 現在、
が使われています。
それで、 GitBook 本体の方では、プラグイン用に使える拡張構文みたいなのは実装されてはいますが、 Markdown 文法に深く食い込んだ構文拡張をしようと思うと、この GitBook そのものの拡張構文ではどうにも上手く行かない場合が有り、その辺り、なんとか出来ないかナーと数日前調べていたところ、
アレ、 GitBook で使われてる
kramed、微妙に拡張できそうだぞ……！
と判ったのでその辺りメモがてらまとめておきます。
先に結論から書くと、 kramed が export している値は、
kramed.Parser = Parser; kramed.parser = Parser.parse; kramed.Renderer = Renderer; kramed.Lexer = Lexer; kramed.lexer = Lexer.lex; kramed.InlineLexer = InlineLexer; kramed.inlineLexer = InlineLexer.output; kramed.parse = kramed; module.exports = kramed;
という感じになっていて、この kramed.Parser や kramed.Lexer or kramed.InlineLexer 辺りをいじれば、
Markdown 構文そのものを拡張できそう
という感じです。
それで、実際にコードとか見ていてこの辺り注意した方は良さそうだなーと思ったのは、kramed の場合、Markdown の Parser と、それ変換して出力する Renderer は別実装となっていて、Parser から直に Renderer の各種メソッドを呼ぶ、みたいな形になってるっぽいので、Parser を拡張して Markdown 構文を拡張した場合、 Renderer も拡張する必要があるっぽい、というところでしょうか。
まあ、この辺りの流れとしては、
- Lexer をいじって Markdown 構文の Tokenize を拡張する
- その拡張部分をサポートさせるために Parser のメソッドも拡張する
- 最後にそれを出力する Renderer の方も対応させる
という感じ (？) っぽいです。
ただ、 GitBook 自体、こういう Markdown 処理系の内部に手を突っ込むコトを想定してないというか、多分、こういうダイレクトアタックみたいなコトを行なうというコトは考えられて作られないと思うので、その辺りの処理拡張で GitBook 処理系がおかしなコトになっても知らん、って感じだと思います。常識的に考えて。そのため、この手法を使うのは奥の手というか、ま、 自己責任で行なってね！ って感じですね。はい。
まーこの手の構文拡張の正攻法としては、 GitBook そのものに備わっている拡張構文使うコトだと思っているので、今回の知見未満な方法は、まあ邪道ではないけど邪法っぽい感じです。
ただ、やっぱり Markdown 自体をいじらないとどうしようも無い場合には、これを使うしかないっぽい、というのはなんともなーって感じですががががが。
まーでも、実際に今回のコレは GitBook の実装がアレっていうより、 自分の要件がアレ って言う感じなので、まあ GitBook は悪くないと思います。はい。
というコトで本日の知見未満は以上。
何かの役に立つかどうか判りませんが、とりあえず個人的には必要なので、雑にメモして終わっときます。はい。
