Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

ReVIEW改訂計画(私案)

考えてみてるだけ。個人の見解です。確定事項は今のところ一切なし。

基本方針

  • 明確な文法
    • 何となくアドホックに処理してるところは全部明確なルール化をしたい
  • 穏やかな移行
    • 新規文法の追加
    • しばらくは古い文法と併存できるようにする
    • コンバータで一括変換とかはしんどそうなので…

ブロックの文法

現状の課題

  • 引数の順序の指定方法が悩ましい(オプショナルな引数を作りにくい)
  • エスケープの仕方に一貫したルールがない
    • ],に特殊な意味がある(場合がある)ので
    • さらにインライン記法を使った場合にやばそう

改訂案

//foo(bar: buz, hoge: "funifuni")

みたいなのはどうか。

  • [...]の代わりに(...)にする←compilerで判別しやすい
  • イメージとしては名前つき引数で、「キー」と「値」のペア(順序による指定方法はなくても死なないはず)
    • 例1: //emlist(caption: "リストのキャプション"){..}
    • 例2: //image(id:unixhistory){ ←でもこの「id:」をいちいちつけるのはめんどいなあ…
      • //image(unixhistory){ みたいに1引数の場合は自動でidにするとかつけるべきか
      • 先頭が/[A-Za-z0-9_-]+:/にマッチしない場合、みたいにできればいいのかな? ←でもハマりそう…
  • 値については""がない場合は「,]」を含まない文字列として解釈
  • ""がある場合は\""\\\に変換、それ以外はそのまま
    • "\が後ろに来ない\の解釈はどうしよう… (例\1 \# \A \n )
  • 要するに複雑なものは""で囲ってもらうように
    • ""で囲うのを必須にすると不便そう

インラインの記法

現状の課題

  • 複数引数があるもの(例: @<href>{...})の構文が破綻気味
    • 複数引数のあるものは,を特別視して、そうじゃないものは特別視しない、みたいなルールになっている?
    • ↑あとから引数を追加したい、となると破綻する
  • @<raw>でビルダーを指定したい件への対応とかも苦しい

改訂案

こちらも、

@<foo>(bar)
@<foo>("bar")
@<foo>("bar", hoge: "funi")

みたいな文法を導入してみるとか。

  • @<foo>の後ろに{}じゃなくて()
  • @<foo>(の直後に「"」が来るかどうかで判別
    • 「"」が来なければ1引数
    • 「"」が来たら次の「"」までが第1引数、あとはキー&値のペア
    • 例1: @<href>(http://github.com/kmuto/review)
    • 例2: @<href>("http://github.com/kmuto/review") ←どちらも可
    • 例3: @<href>("http://github.com/kmuto/review", title: "ReVIEWのホームページ")

CHAPS/PREDEF/POSTDEF

現状の課題

  • そもそも名前が分かりにくい
  • 3つに分けるより1つになってる方が良さそう

改訂案

MANIFESTファイルとかを用意して統合する

  • frontmatter/backmatterの区別は何かしらの識別子を与えて判別できるようにする
    • むしろepub:type的なものを与えられるようにするのがいいかも

入れ子

現状の課題

  • とりあえずできた方がありがたそう?(できないと辛そう?)
    • builderによっては実現不可能な入れ子が出てきそう…(LaTeXとか)

改訂案

…泣きながら頑張って対応する??

画像ファイルの指定方法

現状の課題

  • 拡張子を指定したい
  • Builder別に拡張子を与えた方が幸せになれるのでは?
    • 全てのBuilderで同じ拡張子というのは困る場合がある
    • とはいえ全Builderに対してそれぞれ指定するのは面倒というか拡張性が低くなる

改訂案

(未定。どうしたもんですかね…)

テーブル記法

現状の課題

  • 制限がきつい
    • セルの結合ができない
    • 背景色の指定とか
    • 罫線の有無の指定とか

改訂案

  • //tableではない別記法を導入?
  • いっそHikiDoc辺りから借りてくるのはどうか
    • //htable とか?
@aamine

This comment has been minimized.

Copy link

aamine commented Dec 22, 2013

CHAPSとかのファイルが分かれてるのは、別個に導入したという歴史的経緯の他に、Makefileでcatして読み込めるという理由があったりします。まあでもそれはヘルパーコマンドを作れば済むので、気にする必要はないですが…

引数の文法については、最初に手を抜いて正規表現一発で実装したのがよくないだけで、真面目にパーサー書けばカギカッコのままでも名前付き引数を受け付けるのはたいして難しくないです。単に名前付き引数を導入すれば済むんじゃないかな。

あと文法を混在させるよりは、エラー(と思われる、がありそうな)箇所を見付けるツールを付けるほうが移行は楽なはずです。混在前提になると、そういうツールが作れなくなる。

画像はねー、昔からずっと困ってるんですよね。でもまー基本使い分けが必要なのはせいぜい「プレビュー」と「本番」ともういっこくらいだと思うので、Rails.envみたいな感じでステージごとに画像の優先順位を指定しておいて、最初に見付かったやつを使う、で十分じゃないでしょうか。候補がなくなったときの挙動もステージごとに指定できれば、本番でepsが見付からなかったら即落とすとかできるし。

@takahashim

This comment has been minimized.

Copy link
Owner Author

takahashim commented Dec 22, 2013

おお、よく見たらあおきさんのコメントが! ありがとうございます!

CHAPSについてはPARTが入ってた時点でcatで読めなくなっているような…。

文法は真面目にparser書けば解決するのかもですね。ただ、名前付き引数ってそのまま導入できるんでしょうか…。既存のファイルを壊しそうなのを心配しています。

たぶん今の問題のポイントは、「HTML(EPUB)とPDFとInDesignとでソースを共有する」という点で、それでBuilderごとに必要な引数が違うとか、指定方法を統一するのが大変そう(画像の大きさとか)、というのがあるのでした。LaTeXではPDF画像を使いたいけどEPUBではJPEG画像を使いたくてEPUB内にはPDFファイルを含めたくない、とか。なのでステージごとの違いとは別なのでした。

@takahashim

This comment has been minimized.

Copy link
Owner Author

takahashim commented Dec 27, 2013

記法としては[..]を活かして、名前付き引数のときには//foo[..](bar: buz)みたいに[..]の後ろに(...)を連結させるのがいいかも?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.