合意は取れてないです。2.0くらいで…と思っているのだけれど、全部やるには時間がかかりそうだから、いっそのこといくつかに切り分けて全部やるのは3.0くらいにするべきかも。
「プロジェクト」の概念を明確化する
Re:VIEWはconfig.ymlとcatalog.ymlによる「書籍（≒複数の章の集合体）」を設定するところから始まるのだけれど、簡単に扱うために「章」単位でコンパイルできるようにするしくみもある。が、明確化のためには、書籍単位のデータ・ファイル作成をもっと前面に押し出すべき。
用語としては「プロジェクト」とすればいいような気がする（『はじめてのReVIEW』でも使っていたし）ので、これを公式用語にするのでどうか。
やるべきことは以下。
- review-initを使いやすくして推奨する
- ドキュメントを修正する
Webサイト版を作れるようにする
WEBMaker（仮）を作って、Webサイト用のHTMLを吐けるようにする
Web版には以下の機能が付け加わる。
- サイトメニュー（スマホ向けにはメニュー）で目次が出る
- 次の章・前の章・トップへのリンクがつく
templatesディレクトリを作って、HTMLのテンプレートはそちらに集約する
すでにXHTML1.0/HTML5対応で破綻気味な上に、Webサイト版を作るとどうにもならなくなりそうなので、ちゃんとテンプレート（エンジン）を使うようにする。
とりあえずERbを使えば何とかなるのでは。
なんでも config.yml に寄せる
config.yml以外のオプションは極力排除する。まあ何かしら上書きはできるようにしてもいいけど、「オプションでしか指定できない」ものなくす。
具体的には、review-compileのオプションとして--targetは残す（個別のターゲットを指定できるようにするため）けど、それ以外は--yaml=YAMLで指定できるようにする（--yamlオプションについては後述）。
catalog.ymlとかlocale.ymlもconfig.yml内の設定項目にすることで、暗黙のデフォルトではなくす（が、明示的に指定できるだけで、暗黙ではないデフォルトにはなるのかも）。
config.ymlのparams:でしか設定できないものはなくす
config.yml自体に項目を設けて、そちらで設定するようにする。
config.yml を暗黙のデフォルトにする
kdmsnrさんがこういう主張をしていた気がする。
以前は「環境によってconfig.ymlを使い分ける」派だったのだけれど、それはそれでDRYじゃないというか、いろいろ考えると一つのファイルに集約させたくなりそうかな、というのが今の結論。一つに集約させるのであればデフォルトにしてもいいのかも、という気持ち。
これができると、上記のreview-compileコマンドについても、--yamlオプションがない場合でもconfig.ymlが読み込まれるようになる。これがいいかどうかは不明だけど分かりやすくはあるかも。
環境を指定できるようにする
これは逆にコマンドラインオプションを増やす方向になるのだけれど、--env sampleとか--env printingとかを指定できるようにして、それぞれで違う文書を生成できるようにする。
使い分けたいのは以下。
- 電子書籍版PDF、EPUB: これが標準
- 試し読み版PDF、EPUB: サンプル版で、いくつかの章のみにして（catalog.ymlを変更する）、「サンプル版はここまでです。続きは云々かんぬん」というページを突っ込む
- 印刷版PDF: 表紙なし、モノクロ指定？（画像はどうするんだ…）。
国際化対応を真面目にする
ReVIEW::I18n対応がだいぶ進んだけれど、根本的なところでできていないところもあるので何とかしたい。
- review-initコマンドでは、せめて日本語用と英語用のプロジェクトを作れるようにする
- config.yml の英語版を用意して、英語の時にはそちらが生成されるようにする
review-initのデフォルトが問題で、国際化するのであればデフォルト英語になっていた方がいいような気がするけど、日本人向けにはreview-init --lang ja とか面倒くさいだけなのでちょっと二の足を踏む。
あるいはreview-jinitコマンドとかを追加した方がいいのかも。
parserを置き換える
遅々として進んでいないけれど細々と続けてはいます。
インラインは入れ子にできるようにする
これは実現できそう。
ブロックの入れ子もある程度はできるようにする
これが現状うまくいっていない。
**追記：**どうやらこちらも解決できそう。
ブロックといってもいくつか種類があって、少なくとも2通りの違いがある。
- ブロック内のコンテンツとしてブロックをとるもの（例: //lead{ .. //}）
- ブロック内のコンテンツとしてブロックをとらないもの（例: //emlist{ .. //}）
現在は両者を区別していない。ので、うまくいっていない。
追記: 結局、通常のブロック要素以外にコードブロック要素を導入した。こちらは入れ子を許さず、また改行などの情報も落とさないようにした。
例えばHTMLでは要素ごとにコンテンツとして何が取れるかどうかを決められる（実際HTMLのスキーマではそのように定義されている）のだが、そもそもRe:VIEWではreview-ext.rbなどで後からタグを追加する可能性があるので、要素単位で事前に指定することはできない。要素を追加するときに何かしらの区別ができるよう、しくみを追加しなければならない（どうすんのがいいのかな…？）。
追記： この件については、通常のブロック要素を定義するCompiler.defblockメソッド以外にコードブロック要素用にCompiler.defcodeblockメソッドを追加した。これを使えば、コードブロック要素は後からでも定義できる。
コードブロック要素については、パーサの実行時に要素かどうかのチェックを入れた。
エラーチェックは後で頑張る
最初の時点ではエラーチェックは難しいというか、無理やり解釈してしまいそうな気がする…。
具体的には、中途半端なタグ「@<br> ({}がついてない)」みたいなのをそのまま通してしまいそう（エラーは出さずに、単にそういう文字列があるんだとして解釈する）。ルールを頑張ればエラーにできるはずだけど、そこまでやるのは時間がかかりそうなのでそこは後回しにしたい。