自己顕示欲の開放治療所

erg, programming and something.

別名:Laughing and Grief 雑記

Latin and Greekは習ったこともない

真面目な記事の他、特定の方には不快と思われる事柄に関して言及を行うことがあります。ちょっと頑張りますが、Blog内で解決できなかった場合要望があれば別ページに技術記事は書き直します

ぼくのかんがえたさいきょうの軽量マークアップ言語のためのメモ

そんなものはない

おもったこと

  • Markdownの好きではないところとして、拡張記法が実装言語によってバラつくところがある。
  • CommonMarkはちょっとNotForMeだった。
  • Re:VIEWの記法は結構好きだけど書籍用処理系と構造しか今はない。
  • EWBでは(変換先が決まっていたためでもあるが)意味マークアップと装飾用マークアップが分かれていて分かりやすい。
  • メモやブログの再利用時に手直しの負担が少ない方がよい。
  • 技術書向け以外のための記法(具体的には小説の会話文など)もちょっと欲しい。
  • 変換時に可能なら元のファイル構造を維持したい。
  • 構造によってはパラレルに処理できると嬉しい。

やりたいことともんだい

  • Re:VIEWライクな汎用記法を考えてみる。
  • ドキュメントのインポート機構をつける。
  • セクションは明示的に閉じるようにする。同じドキュメント内で開いたセクションは閉じる。
  • RAWブロック(インライン)系とネスト可能なブロック(インライン)の記法は分けるべきか?
  • 設定ファイル記法。CUE or TOML? ドキュメント本体とは別記法でドキュメントに仕込むことも可能に。処理時に明示する場合
  • 結局ベストなテーブル記法はなんなのだろうか。
  • preproccess, postprocessは汎用言語仕様としては悪手っぽい。
  • 不正なドキュメントは変換失敗でよい。
  • 文書の想定種類 カード(カンバン, コメント部のドキュメントなど)。これを最小単位とする。 アーティクル(カードを内部に含む場合がある)。 ブック(アーティクル、カードを内部に含む場合がある)。 それぞれで可能なセクショニングレベルを分ける。ブックはh1 - h6相当まで, アーティクルはh1 - h5, カードはh1 - h4とする。変換時にブックからアーティクルが呼ばれているといったとき、アーティクルのセクションレベルは1段下がって解釈される。 ** メタデータとしては上位が優先される。セクションオーサーなどのメタデータは別に分ける。
  • 一部のマークアップについて短縮記法を用意する。

Card

  • タイトル(メタデータ)とh1は共通
  • ドキュメントのネストを許容しない

Article

  • タイトル(メタデータ)とh1は共通
  • Cardのネストを許容する

Book

  • タイトル(メタデータ)とh1は別
  • Article, Cardのネストを許容する

TODO

とりあえずこんなところか。