考えてみてるだけ。個人の見解です。確定事項は今のところ一切なし。
- 明確な文法
- 何となくアドホックに処理してるところは全部明確なルール化をしたい
- 穏やかな移行
- 新規文法の追加
- しばらくは古い文法と併存できるようにする
- コンバータで一括変換とかはしんどそうなので…
- 引数の順序の指定方法が悩ましい（オプショナルな引数を作りにくい）
- エスケープの仕方に一貫したルールがない
]や,に特殊な意味がある（場合がある）ので- さらにインライン記法を使った場合にやばそう
//foo(bar: buz, hoge: "funifuni")
みたいなのはどうか。
[...]の代わりに(...)にする←compilerで判別しやすい- イメージとしては名前つき引数で、「キー」と「値」のペア（順序による指定方法はなくても死なないはず）
- 例1:
//emlist(caption: "リストのキャプション"){..} - 例2:
//image(id:unixhistory){←でもこの「id:」をいちいちつけるのはめんどいなあ…//image(unixhistory){みたいに1引数の場合は自動でidにするとかつけるべきか- 先頭が
/[A-Za-z0-9_-]+:/にマッチしない場合、みたいにできればいいのかな？ ←でもハマりそう…
- 例1:
- 値については""がない場合は「,]」を含まない文字列として解釈
- ""がある場合は
\"は"、\\は\に変換、それ以外はそのまま"や\が後ろに来ない\の解釈はどうしよう… (例\1\#\A\n)
- 要するに複雑なものは""で囲ってもらうように
- ""で囲うのを必須にすると不便そう
- 複数引数があるもの(例:
@<href>{...})の構文が破綻気味- 複数引数のあるものは
,を特別視して、そうじゃないものは特別視しない、みたいなルールになっている？ - ↑あとから引数を追加したい、となると破綻する
- 複数引数のあるものは
@<raw>でビルダーを指定したい件への対応とかも苦しい
こちらも、
@<foo>(bar)
@<foo>("bar")
@<foo>("bar", hoge: "funi")
みたいな文法を導入してみるとか。
@<foo>の後ろに{}じゃなくて()@<foo>(の直後に「"」が来るかどうかで判別- 「"」が来なければ1引数
- 「"」が来たら次の「"」までが第１引数、あとはキー＆値のペア
- 例1:
@<href>(http://github.com/kmuto/review) - 例2:
@<href>("http://github.com/kmuto/review")←どちらも可 - 例3:
@<href>("http://github.com/kmuto/review", title: "ReVIEWのホームページ")
- そもそも名前が分かりにくい
- 3つに分けるより１つになってる方が良さそう
MANIFESTファイルとかを用意して統合する
- frontmatter/backmatterの区別は何かしらの識別子を与えて判別できるようにする
- むしろepub:type的なものを与えられるようにするのがいいかも
- とりあえずできた方がありがたそう？（できないと辛そう？）
- builderによっては実現不可能な入れ子が出てきそう…(LaTeXとか)
…泣きながら頑張って対応する？？
- 拡張子を指定したい
- Builder別に拡張子を与えた方が幸せになれるのでは？
- 全てのBuilderで同じ拡張子というのは困る場合がある
- とはいえ全Builderに対してそれぞれ指定するのは面倒というか拡張性が低くなる
(未定。どうしたもんですかね…)
- 制限がきつい
- セルの結合ができない
- 背景色の指定とか
- 罫線の有無の指定とか
//tableではない別記法を導入？- いっそHikiDoc辺りから借りてくるのはどうか
//htableとか？
CHAPSとかのファイルが分かれてるのは、別個に導入したという歴史的経緯の他に、Makefileでcatして読み込めるという理由があったりします。まあでもそれはヘルパーコマンドを作れば済むので、気にする必要はないですが…
引数の文法については、最初に手を抜いて正規表現一発で実装したのがよくないだけで、真面目にパーサー書けばカギカッコのままでも名前付き引数を受け付けるのはたいして難しくないです。単に名前付き引数を導入すれば済むんじゃないかな。
あと文法を混在させるよりは、エラー（と思われる、がありそうな）箇所を見付けるツールを付けるほうが移行は楽なはずです。混在前提になると、そういうツールが作れなくなる。
画像はねー、昔からずっと困ってるんですよね。でもまー基本使い分けが必要なのはせいぜい「プレビュー」と「本番」ともういっこくらいだと思うので、Rails.envみたいな感じでステージごとに画像の優先順位を指定しておいて、最初に見付かったやつを使う、で十分じゃないでしょうか。候補がなくなったときの挙動もステージごとに指定できれば、本番でepsが見付からなかったら即落とすとかできるし。