Kenshi Muto

jlreqでlistingsのbreaklines=trueが無視されるのはlistings側の問題っぽい感じがしますね…。 いずれにせよlistingsだといろいろ厳しいので、mintedのほうが安定しそうです。

遅くなりました。colophon:trueで自動生成の場合producerの最後のほうで生成される、verify_target_imagesは画像コピーのタイミング上もっと前なのでそのときにはcolophonファイルはない、と。 全体まで直すのはしんどめなので、verify_target_imagesでcontent.fileがなかったら単にスキップするようにするのがいいのかなと思っています。

warning: literal string will be frozen in the future キッツ。 ``` s = '' s

デフォルトの10000はたしかにちょっと小さいことがありそうだなとは思いつつ、では妥当な数値は、となると確かに難しいですね…。configパラメータ化してもエラーから設定への誘導動線が難しそう(それならreview-ext.rbで十分ではとなりそう)。

え、すごい > Builderを全く別物のRendererに置き換えることの是非 私は気にしないです。メジャーバージョンは変える必要はありそう > 記法の拡張性はどのくらい必要かどうか ブロックはまぁまぁ拡張することがありましたが、公式化していけばいいのかもしれない? extによるモンキーパッチはどのくらい大変でしょう? > 古い互換性は維持するべきかどうか（このタイミングで整理するのはどうか） メジャーバージョン変えるなら無理に維持しなくても。 > Markdown入力を正式に対応するかどうか pandoc2reviewでなんとかする案件もあったりしたので、marklyがたいていの拡張Markdownに対応できるのであれば、正式にRe:VIEWでサポートされるのはよさそう。

うーん、なんかS式構文っぽくなるんだろうか。雰囲気的にはこういうことでしょうか。 ``` //ol{ //li{ liの段落 * 箇条書き * 箇条書き liの段落2 //} # li閉じ //li{ //ul{ //li{ 箇条書き段落1 //image[][]{ //} 箇条書き段落2 //} # li閉じ //} # ul閉じ //} # li閉じ //}...

脚注という意図は変わらないのでインライン記法を別に、はしづらいですね。 - 設定で挙動分岐？ - Vivliostyleビルダを追加？ EPUB生成までがセットなので結局epubmakerもいじらないといけなくなる と考えると、HTMLBuilder内で設定で分けるのが無難そうかなぁという見立てです。