デラングという軽量マークアップ言語を開発していて学んだこと。Markdown のコードフェンス ``` は `` で何の問題もないし，区切り線 --- は -- で何の問題もない。むしろ，なぜ3つ以上にしたのか謎である。

（進捗時限記録中略）

不意に閃いた「階層区切り線」についての方針をまとめて終了。

従来の見出し未満の区切り線記法に，見出し階層を越えられる「階層区切り線」を加える。以下のように，唯一通常の区切り線と区別出来る見出し記号 #（全角 ＃ も可）を使う。

* 第1階層
** 第2階層

#========================#

第1階層段落。

#------------------------#

第2階層段落。

#- - - - - - - - - - - - #

第3階層段落。

#. . . . . . . . . . . . #

第4階層段落。

##

第1階層段落（# の数でも調整出来る）。

持ち辺（モチベーション）

従来の区切り線記法は，HTML において対応する <hr> の性質上，見出し未満の区切りにしか使えなかった。

見出し階層を作った後で描写全体に対するフッター的なものを書こうとすると第1階層見出しを作る必要があるが，しばしば大袈裟に感じられることがある。

検討過程

「空見出し」の挫折

今回の検討当初は，「空見出し」という概念を主に考えていた。区切り線の長さは任意であるべきなので，どう弄っても自然な形で階層を調整出来そうになかった。その点，見出し内容を空に出来れば手っ取り早い。

しかし，等号も星号も区切り線に使う予定なので，== のように第2階層以降で内容を空にすると衝突することになる。

区切り線の方を見直しても，-- が区切り線なら == はやはり二重の区切り線であってほしい。直感性，下線形見出しとの整合性を考えるとこれは捨て難い。星号による区切り線はそれに比べればまだ転用の余地があったが，その代わり * を使う Markdown の区切り線記法との互換性が損われる。

そもそも，「空見出し」という概念にも無理がある。文字を書くから見出しなのだし，実質的に区切り線なのだから，直感的とは言い難い。

「階層区切り線」の閃き

ここで，唯一区切り線記法と被らない見出し記号である番号記号を思い出した。

番号記号による見出しは，ハッシュタグや駒手記法との衝突を避けつつ atx 式見出しとある程度互換性を持たせるため，## のように2個以上を条件に対応していた。個人的に好きな記法ではなかったこともあり，おまけのような扱いで，ここまで気付かなかった。

すでに「空見出し」に難を感じていて，区切り線記法での対応に立ち返っていたことで，この ## が特殊な区切り線とみなせる特徴を持っていることに気付いた。記号を2個以上繰り返す，区切り線に見える記法で，実際，普文の枠線的な装飾に使われることが多い記号でもある。

特に，区切り線記法としての統一感・直感性を保てる2個で第1階層を表せるということは決定的に重要な点で，見出し記号の個数と階層関係が一致しないとどうしてもちぐはぐに見えてしまう。これは，衝突を回避したとしても等号・星号では解決出来ない問題だ。区切り線記号としての最短形が見出し記号としての第1階層に対応しうる唯一の記号が番号記号だった。

ただし，通常の区切り線記号と異なり，個数が階層に対応するため，普文の装飾を兼ねられないという問題があった。上位階層の区切り線を普文上で目立つように書けない。

これは，最新の区切り線記法と下線形見出し記法の検討（9日17歩，19歩）を踏まえ，見出し階層に対応する4種の区切り線と組み合わせる形で解決することにした。つまり，第1階層から順に最短形で #==#，#--#，#- -#，#. .# というように区切り線と組み合わせることが出来るようにする。これがまた都合が良いことに，よくある装飾に見える。

9日15歩以後，見出しの下線と区切り線は長さで区別出来るようになっているため，区切り線の装体にはある程度多様性を持たせて問題ない。一方，見出しの下線は階層を表す装体になっているため，一定の制限が必要になる。この点でもぴったり噛み合った。

別に2個以上で良いだろうと実装した区切り線記法，おまけ感覚で付けた番号記号による見出し記法，最近の拡張方針……何気ない全てがパズルの要素だったかのように思える神秘的な閃きだった。

番号記号見出し仕様の厳密化

この階層区切り線の考案を機に，番号記号による見出しは常に2個を最上位階層とすることにした。つまり，*，= と ## で始まる見出しはともに最上位階層を表す。

これまで，異なる見出し記号を併用することは特に想定しておらず，実際使われていないはずなので，記号の個数は単純に計算していた。見出し階層は相対的な個数で決まるため，* で始まる見出しがあると ## は第2階層になる。これは階層区切り線と整合しない。

特に仕様として決めていたことではないため，ここで厳密化することにした。

実装上の課題

仕様は完璧に思えるが，実装上の課題は残った。

HTML と CSS の機能的には，可接性を保ちつつ見出し要素を隠すことは造作もないが，SEO 上の懸念が多少ある。今の検索演心の評価理積みはそこまで単純ではないだろうが，伝統的に見出し要素は隠すべきではないとされてきただけに，どこまで不利になるか分からない。出来るだけ行儀の良い実装方法を見つけたい。

そもそも見出し要素を空にしてはいけないのか，<section> あたりを使って上手く誤魔化せないか，など色々考えてみたが，どれも多かれ少なかれ怪しさが残る。

見出しの無い階層区切りというのは HTML の想定外だったのだろう。

（進捗時限記録中略）

ひょんなことから，予てからの課題だった折り畳み記法が急速にまとまった。

折り畳み記法は，他の部区記法と組み合わせて使える汎用的な記法として実装していくことにした。以下のように，部区の開始行末に ^ を加えることで，その部区（見出しなら階層下の内容）が折り畳まれるようにする。厳密に言えば見出しは階層下の内容を含む部区ではないが，例外的に扱う。

・リストの折り畳み ^
  ・折り畳まれる項目

* 折り畳む見出し ^
折り畳まれる内容

+{埋め込みの折り畳み K#XXXX} ^

検討中，これがネタバレや NSFW のような閲覧注意の内容に使えそうなことにも気付いた。

きっかけからまとまるまで

補足記法・注意記法についての検討で，終了記号に区切り線（--）も使えるようにすることを考えた時，以下のように区切り線の亜種として ^^ を使って折り畳めることを示してもいいのではないかと思い付いたことがきっかけだった。

?? 補足
補足内容
^^

この終了記号のように，他の部区にも統一的に応用出来る記法があれば何かと可能性が広がる。そこであれこれ検討してみると，部区の終了記号だけでなく開始記号側にも分かりやすい目印が欲しくなった。むしろそちらの方が自然な場合が多い。

^ に対応する記号なら v が考えられるが，Cμ などと異なり自然言語を扱うデラングでラテン文字は導入しにくい。日本語はともかく外国語で問題が起きないとも限らない。

何より，下向きの三角形が一般に展開されていることを表す記号なので，折り畳まれている記号として v を開始記号に添えるのは直感的ではない。となると，< も > もデラングではある程度活用の方向性が決まっているので，矢印的に使えそうな ASCII 記号は ^ しかない。

ここで，「行末に ^」を思いついた。これなら折り畳みの記号としての直感性もあり，他記法とも組み合わせやすい。パンくず記法で「行末に >」を採用する直前にあった案だが，微妙な違和感があり回避していた。この直感が大当たりだった。

そして終了記号の ^^ とも整合的に見える……と考え出したところで，今度はこっちの問題が気になってきた。まず，日本人の感覚ではぱっと見顔文字に見える。そこで，-- の亜種であることが分かりやすいように --^ を考えてみたが，空行を挟まないと特定の文字を指しているような記号に見える。

そもそも開始行末に1個あれば，特別な終了記号は要らないことに気付くまで時間はかからなかった。結果的に，非常にすっきりした形になった。

他の検討案

昨年6月18日の開発時点からは，以下の2案があった。

++ ラベル
折り畳まれる内容
--

? ラベル
折り畳まれる内容
!

前者がこれまでの最新案で，区切り線の -- と対応させて，++ を使う。ツリーの開閉記号にしばしば + と - が使われることに引っかけた案だったが，埋め込み記法（渡括記法）との紛らわしさから現時点での採用は考えにくい。特に最近では ++ を使った行内埋め込み記法を有力視していることもあった。無理に区別出来なくはないが，意味的な整合性を確保するのが難しい。

後者は，補足記法・注意記法の方向性が固まった今となっては採用の余地も皆無だが，当時から今回の検討のきっかけになった補足記法との組み合わせを考えていたことを示す案であり，歴史的な意義を感じさせてくれるものではある。

（進捗時限記録前略）

補足記法・注意記法についての検討で終了。

概ね以下のような形で実装していくことにした。

??
軽い補足
??

???
重い補足
???

!!
軽い注意書き
!!

!!!
重い注意書き
!!!

終了記号には開始記号のほか区切り線（--）を使うことも出来る。また，開始記号に続けてラベルも指定出来るようにする。

少し前から，この手の記法を導入するとしたらどうするか考えていたが，これ以上直感的な記法は無さそうなのでこの方向で固めることにした。

記号の数は，2個以上4個未満と4個以上を軽重の基準にしようと思ったが，ややこしくなりそうなので2個と3個以上に単純化した。