デラング整備，注意補足記法実装が一段落（10歩），文字装飾記法実装が一段落，輪結記法改良，重い強調輪符改良。

Cμ 文字列処理改良前に片付けておきたかったデラングの課題はこれで概ね片付いた。あと2つほど片付けたいことを片付けたら気持ち良く文字列処理改良に入れる。

（進捗時限記録中略）

一昨日分のまとめ続き。

途中で終了。

18歩のまとめが終わったが，まとめ中に2つの思い付きがあった。

• 「渡括記法」は「埋め込み記法」の一種とすべきか
• 廃案となった（文字装飾記法の）色記法の色見本記法への転用

（進捗時限記録中略）

Markdown の setext 式見出しをどうデラングの見出し記法に取り入れるかの検討で終了。

区切り線と混乱しないようにというのが課題だったが，現在のデラング実装では，段落直後に続く区切り線記法が機能していないことに気付いた。明確に意図していたわけではないはずだが，既存輪郭についての心配は要らなくなった。好都合な偶然だ。

とはいえ，省割として空行を挟まずに使える利便性も捨て難いので，5日3歩の方針は維持すべきか。

= か - を3つ以上というのは，2つは体裁を考えずに省力のために使うことが多いということと，3つ以上で区切り線を引こうとする人なら Markdown の setext 式見出しにも気を付けるだろうという狙いがある。

これと，最新の見出し装体，前歩の区切り線記法についての検討を総合すると，以下のように破線・点線を加えた拡張の可能性も見えてきた。

第1階層
=======

第2階層
-------

第3階層
- - - -

第4階層
. . . . 

（進捗時限記録中略）

デラング整備，越化記法と越化参照（旧・疑似実体参照）についての検討で終了。

越化（エスケープ）の基本的な仕様について記法・内部実装両面から急速にまとまった。

単一文字越化

まず，バックスラッシュを使った単一文字越化では，全ての文字を越化することにした。ただし，この「越化」は，「通常とは異なる特殊な解釈を試みること」であり，論組言語等でのそれと同様，必ずしもデラング記法としての解釈を避けることではない。

• 原則として，デラングの特殊文字であるかどうかにかかわらず，どの文字に対してもバックスラッシュを削除して当該文字を維持する。
• ただし，数式記法における \[ ... \] や \( ... \) のように，通常特殊文字として解釈されない文字に特殊な意味を与えることにも用いる。

非特殊文字の扱い

軽量標記言語で単一文字越化の対象を非特殊文字に付けた場合の挙動としては，「不明なエスケープシーケンス」などと違了を出すわけにはいかないので，以下の2つが考えられる。

• 非特殊文字に対しては何もしない（バックスラッシュも削除しない）。
• 非特殊文字も内部的には越化する（結果としてバックスラッシュは削除される）。

普段非特殊文字にあえて越化文字を付けてみることなどないので，一般的にどう実装するものなのか分からなかったが，特に定石があるわけではなさそうだ。

当初はなんとなく前者を想定していたが，この場合，全ての特殊（になりうる）文字を予め定義しておく必要があり，挙動の変則性が用者を混乱させる懸念もある。デラングの場合は文脈によって特殊文字になったりならなかったりすることも多いため，その対応も含めるとかなり複雑化してしまう。

後者の方が分かりやすいといえば分かりやすく，先日交度記法で出来た代置子方式を応用すれば実装も単純化出来る。数式記法などでは越化対象文字を判別する必要があるが，これは代置子への置換処理の前に制御子に置換すればいい。

いずれにせよ後から変更するのが難しい仕様ではないので，まずは実装の単純性を取るべきだろう。

数式記法との整合性

越化記法との整合性を深く考えず，LaTeX 方面の慣習に従い導入した数式記法の \[ ... \] や \( ... \) をどうするかという問題に少し手間取った。

これまで越化記法も「デラング記法としての解釈を避ける」ためのものとして想定していたが，ここで本来の越化という概念に立ち返り，「通常とは異なる特殊な解釈を試みる」ためのものとすることで整合させることにした。

越化参照

単一文字越化で「越化」という概念を捉え直した結果，これまで Dex で「疑似実体参照」と呼んでいたものを「越化参照」として再定義することが出来た。

これに伴い，疑似実体参照では &_foo; としていた記法を，越化の意が直感的に分かりやすい &^foo; に統一することにした。代置子は &^[連番];，「制御子」（ここで命名）は &^[名前]; となる。

越化用の代置子に関しては &^1; などと書き分けるかと考えたのとほぼ同時に前述の越化概念の拡張があり，そもそもこれまで「疑似実体参照」と呼んでいたものが越化列の役割と同じであることに気付いた。

参照先に実体があるわけではないので「疑似実体参照」という名称にはずっと違和感があったものの，良い代替案が見つからなかった。これで越化記法の課題と同時に解決してしまった。

（進捗時限記録中略）

埋め込み記法（渡括記法）の応付子（オプション）などについての検討で終了。

概ね方針が固まってきた。

引数風の応付子

これまで埋め込み記法には，埋め込み方を細かく指定するような機能がなく，例えば画像埋め込みでも表示サイズや水平方向の寄せ方を指定出来なかった。この問題は当然当初から認識していたが，どうしてもごちゃごちゃしがちな部分なので，直感的で美しい記法を練るのに時間がかかった。差し当たり欲しいのは画像埋め込みで表示サイズや寄せ方を指定出来る機能だが，他の埋め込み対象でも使える汎用的な枠組みを整えておきたい。

そこで，[寄せ方指定スペース]+([応付])[埋め込み対象] の形式を採用することにした。例えば，添付譜類の PNG 画像を100x100で埋め込みたい場合，+(100x100)png と書けるようにする。

丸括弧内は，函数引数風にコンマ区切りで，埋め込み対象毎に使える応付子を設定する。引数名を指定出来るように a=x や a:x を受け取ってもいいが，柔軟性も必要なのであえて必須にはしない。スペースを含む文字列を扱いたい場合も考えられなくはないのでとりあえずコンマ区切りにしておくが，各引数の扱いは駒手欄の感覚に近い。

他の案として，+100x100 png や +100x100,png のように全てを引数的に扱うことも考えたが，あくまでも埋め込み対象を主とする応付の役割とまとまりが一番分かりやすいという点で丸括弧を採用する。また，埋め込み対象は URL など長い文字列になることも多いため，応付は + の直後に置く。あるいは，末尾に置く形と書き分けられるようにする。

水平方向の寄せ方

水平方向の寄せ方は，表組み記法で採用予定のスペースを使う方法を応用することにした。以下のように，+ 前のスペース無しは無指定，4つ未満は左寄せ，4つ以上で中央寄せ，6つ以上で右寄せとする予定。

+png            <!-- 無指定 -->
  +png          <!-- 左寄せ -->
    +png        <!-- 中央寄せ -->
      +png      <!-- 右寄せ -->

直感性でいえば矢印のような記号を導入することも考えられる。となるとまず < と > を使うことになるが，すでに多用しているため無闇に役割を広げると記号の意味が稀薄化しかねない。そうでなければ left，center，right のようなキーワードを導入するくらいしかないだろう。いずれにせよ，見た目的にもあまり美しくない。

当初，以下のようにスペースの数も表組み記法に合わせようとした（2つで中央寄せ，3つで右寄せ）が，いくつか問題がある。

+png         <!-- 無指定 -->
 +png        <!-- 左寄せ -->
  +png       <!-- 中央寄せ -->
   +png      <!-- 右寄せ -->

まず，表組みにおけるセル内での編集に比べそこまで編集効率は問題にならないためここまで短くする必要もなく，比較的長くなる後続文字列に対して目立ちにく過ぎる。単純に，スペース2つで中央寄せ，3つで右寄せの表現には見えない。

さらに致命的な問題は，いくつかの他記法との整合性だ。導入予定の字下げ記法では，行頭に全角スペースを使う。あまり好きな記法ではないが，Markdown の4つの半角スペースを使う交度記法も互換性のため導入する可能性がある。これらの記法を混ぜて書いた場合，視覚的な整合性が取れない。

そこで，行頭に使う寄せ方指定のスペースは表組み記法の倍とすることにした。交度記法にも使われる4つの半角スペースが右寄せに一致するよりは中央寄せに一致した方が違和感がずっと小さい。

行内埋め込み記法

おまけに，行内埋め込み記法についても少し考えた。

これまで埋め込み記法は部区として扱うことを主に考えてきたが，やはり行内埋め込みも必要だろう。まだ草案の段階だが，例えば以下のようにして画像に回り込む段落が作れると便利だ。

++png++ 左上の画像に回り込む段落。

中途半端なので外付け HDD の既存場当て（FAT32 と ext4 の2つ）を全て削除し，新規作成，ext4 でフォーマット，手定めを兼ねて rsync -av ... を実行しておいた。

これで抜控環境整備は kn bup-xhdd の実装を残すのみとなった。

分割格納方式への移行作業で終了。

これまで Windows 仮想機では自我台録を共有フォルダにして直接知番譜台を読み書きしたりしていたが，分割格納方式になり kn kno の自動知番譜台化も出来ることで Windows で知番譜台の新規作成をすることはもう無さそうなので，今後は ~/K#/ と ~/tmp/ の2つの共有フォルダを使い分けることにした。Windows 側で新規作成する場合は適当な名前で ~/tmp/ に保存し，kn kno で知番譜台化する。いずれにせよ ~/tmp/ は便利だろう。

本台録の共有も試してみたが，制危上共有範囲は最小化しておいた方がいいのとドット譜台など邪魔な譜台が多かった。

ついでに軽く Windows 仮想機のデスクトップ整理もしておいた。

アンダースコア略記法や内包子におけるアンダースコア記法の廃止についての検討で終了。

現状，譜類名（例：._acv）・台録名（例：/_kn/）・駒手名（例：_kn）などにアンダースコアを接頭子や略記法として多用していた時期の名残りが多くあるが，ほとんど活用していないため，いったん廃止することを決めた。

アンダースコア略記法やその応用記法の問題は，明示性・簡潔性ともに中途半端で，現実には使いにくいという点にある。より簡潔な記法や冗長な記法があると使い分け方が無駄に増えややこしいし，使い所が無い。

知機駒手では大分前から _kn よりも kn を使うようになっているが，9月9日13歩以後はこの kn も省けるようにしたため，_ の出番は完全に無くなってしまった。結局 _ よりも kn を使ってしまう理由は，どうせ面倒臭いなら分かりやすい方が良い，ということだった気がする。

これまでの経験上，十分明示的な冗長記法と短縮記法の2つにまとめていくのが一番良さそうだ。

KNIF に使っていたアンダースコア記法も廃止し，代わりに kn- 接頭子を導入することを決めた。

例えば，これまでの ._acv は冗長表記で .kn-acv，短縮表記で .acv となる。知機駒手同様，混同の恐れが無い場合は原則として短縮表記を用いる。

.kn.acv のようにすることも考えたが，一つの拡張子として認識されないと不都合なこともあるので，MIME 型（application/x-kn-acv）や正式名称の初期案に合わせる。KNIF の各形式に与える正式名称は，旧称 KFF の時は KFF- 接頭子，KNIF になってから KN-ACV のような KN- 接頭子になり，一時 KNIF_ 接頭子に揺らいだこともあったが（冗長過ぎる），これを機に KN- 接頭子で確定する。

アンダースコア記法に依存した実装を排除しながら段階的に置換を進めていく。

ネット環境整備，USB 配線整理。

Archer T4U Plus が USB 3.0 対応なので USB 3.0 ポートが使えればと思ったが，とりあえず他のポートで USB 配線整理を済ませておいた。

T4U Plus の設定作業を始めた13時頃から22時過ぎ現在まで，T2U Nano で見られたような不安定化は一度も見られず，非常に快適に使えている。もう数日は様子を見たいが，これがほぼ完成形だと思って良さそうだ。

• これまで T2U Nano を挿していた筐体前面下段左は，臨時用途で空けておくことにした。
  • T2U Nano は T4U Plus 故障時の予備として箱にしまっておく。
• 印刷機（プリンター）を挿していた筐体背面上段左に T4U Plus。
  • 印刷機向かって右に置くのにケーブルの長さは丁度良かった。
  • T2U Nano の背面ポートでの不安定化が激しかったため，相性がどうかと思ったが，筐体前面下段左と比較しても有意差は見られなかった。内蔵アンテナにはノイズが強い位置だったのかもしれない。
• ハブを挿していた筐体背面上段右に印刷機。
• 1つだと思い込んでいた筐体背面中段のポートが2つあったので，左にハブ，右を外付け光学ドライブ・外付け HDD 共用。

全体的に各周辺機器の配置に近く，抜き挿し頻度の高いポートは手の届きやすい位置に来るようにと，合理的になった。各機器動作確認済み。

一応写真も撮っておいた。