臨時休業したためのんびり作業したが，収穫はそこそこだった。

まず，輪郭選り手抜控機能整備の出振るい後，気になった問題を概ね解消した。これで気持ち良く次の当努に移れる。今後の作業方針についての考えもまとまりつつある。色々な気付きもあったが，早く寝たいので作業時に書く。

• 再描出下書き抜控の読み取りを自我毎に出来ていなかった問題を修正。
• 実質内容のない新規描出下書き抜控が残りやすい問題に暫定対応。
• 知名・描写の片方しか下書き抜控がない場合でも合体選り手を開くように修正。
  • 挙動面でまだ若干混乱があるため暫定対応。
• 新規描出下書き抜控一覧のラベルを「下書き」から「他の下書き」に変更。
  • 再描出下書き抜控一覧とともに「下書き」で統一，波括弧・角括弧のみで区別していたが，性質の違いが分かりにくかった。
  • 付け加え過ぎると冗長感が強くなり，かえって直感的な理解を妨げるのでこのあたりが落とし所か。

描写欄の高さの問題をきっかけに自動リサイズ機能と字数計の実装が出来た。ほか装体調整など。

出振るい済み。

自動リサイズ機能

旧輪郭選り手では，描写欄の出放りの高さを新規描出フォームで10em，再描出フォームで15emとしていたが，新輪郭選り手ではたまたま15emで統一されていた（画面撮り）。10emでは長文が書きにくいのでこれはこれでいいかと思ったが，やはり新規描出フォームは一言だけや知名だけの描出に使うことも多いためこの高さでは邪魔臭い。

ここで，予てからぼんやり検討していた自動リサイズ機能の導入を考えた。一応 resize: vertical は設定してあるが，万能ではない。10emから20em程度までの範囲で，改行毎に自動リサイズさせる。導入予定の字数計では字数情報が必要になるため，一緒に行数も保持させることにした。

実際に試してみると，1em刻みでも2em刻みでも違和感があったため，10emから19emまで1.5em刻みでリサイズするようにした（画面撮り：初期状態，最大自動リサイズ）。19emだと個人機でも低過ぎず高過ぎず，スマートフォンの縦向きで柔品キーボードを表示させてもちょうど収まる程度の高さになる。折り返しの多い1行もありうるため，厳密にするなら字数も考えるべきだが，とりあえずはこれで様子を見ることにした。

再描出フォームに関しては，さほど目立つものでもなく，描写部の高さに合わせて描写欄が開くようになっている現仕様が悪くないので，現状維持で様子見しておく。

字数計

字数・行数の保持が出来たことで字数計も難無く実装出来た。描出ボタンか時印の左側に邪魔にならないように表示させてみた（字数計の様子）。

下見の字数と分けようかと思っていたが，下見を開いている時は下見の字数に置換すれば十分であることに気付いた。一応，見分けが付くように頭に「→」を付けるようにした。

これも，厳密に考えると特殊な文字符号などを考慮する必要があるが，キリがないのでとりあえず .length による概算でよしとしておく。

字数計は，地味ながら意外に需要があることを市場調査を通して知った。自分でもたまに欲しくなることがあった。

（進捗時限記録中略）

Cμ 文字列処理改良，rgx_T の置換道手の引数順序変更，客体表現への書き換え。

込み入っていた数式記法と交度記法の越化処理を代置子方式で統一しつつ，客体表現化を終えた。これをもって既存記法の客体表現への書き換えは完了とする。

この作業により交度の見通しが劇的に良くなり，多少体感出来る程度の高速化も出来た。基本的に理腑なので解決していない不具合もまだ多いが，今後の不具合修正は捗りそうだ。

Cμ 文字列処理改良はまだ緒戦だが，この段階で期待以上の高速化が出来たことは嬉しい。客体表現の強力さも実感出来た。

（進捗時限記録中略）

kitetu.com のサブドメイン設計についての検討で終了。

今後，デラングのように独立して参照出来るべき献典には積極的にサブドメインを与えていくことにした（例：dlng.kitetu.com）。

デラング的転回と同時にデラング文書に dlng.kitetu.com を与えることを決めたが，これを機に，知番や Cμ，SLFS 等々の公式文書にもサブドメインを与えることを考え始めた。

これまでサブドメインの追加には消極的で，例えば技術系の献典は tech.kitetu.com に集約することを考えていた。ただ，この手の URL 設計は，運営者にとっても閲覧者にとっても直感的でなく情報過多になりやすい上，階層的な整理が難しいことも多々あり，変更に弱く参照可能性の低い URL が出来がちであるという問題があった。

こういう場合の対策として，経験上「最短原則」が最善であることは分かっていて，最近は駒手にせよ各種識別子にせよ知名（最短知名原則）にせよ最短化する流れにある。サブドメインについてもこれに従うことにした。希哲館事業の要素は全て kitetu.com の階層下にある，ということだけは確かだ。もちろん，これとは別に，階層的な情報源もあった方がいいので，そこは tech.kitetu.com などに担わせる。

献典にドメインとしての独立性と統一感を同時に持たせられるのだから，むしろ，ここからがドメイン名統一の本領発揮になりそうだ。

2文字サブドメイン問題の解決

サブドメインを活用していく上で，一つ，「2文字サブドメイン問題」とでもいうべき問題があった。

例えば，Cμ にサブドメインを与えるなら cu.kitetu.com とするのが自然だが，CU はキューバの国家符号だ。

ドメイン名統一によって ccTLD を使わなくなっているため，将来的に地域別ドメインが欲しくなった時にはサブドメインを使うことになる。2文字サブドメインの使用は避けるべきかもしれない，と考えていた。キット＊メーネの mn.kitetu.com もモンゴルの MN に被っているのが少し気になってはいた。

ただ，その懸念も「もやもや」の域を出ていなかった。明らかに紛らわしいサブドメインは最初から使わないので，被るとしたら普段意識しないようなものだ。被ったとして，ドメインハックで ccTLD も有名無実化している今，そこまで神経質になることでもないだろう。そんなことのために，わざわざ不自然な表現もしたくない。とはいえ，サブドメインの選択肢が多いに越したことはない。

そこで，国家符号を表す何らかの接子の導入を考えた。Facebook のように，ja-jp と言語符号付きを基本として，言語符号がいらない場合は x-jp のように表記出来るようにするかとも考えたが，少し野暮ったい。

最終的に，4 接頭子を導入する方向で検討を進めることにした。例えば，キューバ向けのドメインは 4cu.kitetu.com として cu.kitetu.com と区別出来るようにする。衝突しなければ 4 接頭子は省略してもいいし，4ja のように言語符号に代えられてもいいだろう。4ja-jp のような表現が出来てもいい。これなら十分な簡潔性と柔軟性を兼ねられる。

例えば 4jp.kitetu.com なら www.kitetu.com と変わらない標準的な長さだし，むしろお洒落感すらあるので，これで統一して，4 接頭子無しは転送用にしてもいいくらいかもしれない。

いまのところ地域別ドメインの必要は感じておらず，将来的に必要になるかもしれない，という程度の問題なので，細かいことは追い追い決める。とりあえず理論上はすっきりしたので良かった。

（進捗時限記録中略・前後）

何気なくマイクロブログサービスの用者（ユーザー）を示せる記法が欲しいという考え事をしていたら「外部サービス利用者記法」に発展したので，軽くまとめて終了。

とりあえず，分散型 SNS で使われている記法を拡張し，@[用者名]@[ドメイン名] の汎用記法を整備する方向で進めることにした。

要は，@user と書いたら Twitter に輪結したり，@user@example.com と書いたら分散型マイクロブログの捌き手に輪結してもいいのではないか，と考えたことがきっかけだった。

ここで一つ，@user@example.com は https://example.com/@user に必ず対応するのだろうかという疑問が湧いた。以前にもなんとなく考えたことはあったが，ActivityPub というか Webfinger で URL を引き出したり，面倒臭そうな気がして進展しなかった。このあたりの仕様がどうなっているのか，いまだによく分からない。

もっとも，ざっと見渡す限り分散型マイクロブログの捌き手は大体 https://example.com/@user になっているし，自分で Mastodon 捌きを運営していた時も出放りはこれだったので，事実上の標準とみなしていいのかもしれない。

Twitter は @user でいいかと思っていたが，いくら普及しているとはいえ，これは特定サービスに寄り過ぎだろうということで，@user@twitter.com で統一することを考えた。ただ，Twitter のプロフィールページの正規 URL は https://twitter.com/user だ。https://twitter.com/@user でも転送されるとはいえ，若干気持ち悪い。

さらに，この時点では @user@twitter.com と書けば @user と表示されるという仕様を考えていたため，いずれにせよ特定サービス向けの処理を追加出来るようにする必要があった。

ここまで考えたところで，いっそのこと @[用者名]@[ドメイン名] として，外部サービスの用者を指すための汎用的な記法にしてしまえばいいのではないか，と思えてきた。これは，B̅ 氏が独自に同様の記法を使っているのを見ていたことが大きかった。

[ドメイン名] は，@[用者名]@twitter のように自明なら短縮出来るようにしてもいいかもしれない。対応サービス毎に用者名を解釈，輪結先を調整し，それ以外は https://[ドメイン名]/@[用者名] に輪結する。

少し困ったのは，簡潔で分かりやすい名前が見つからないことだ。一応平たく「外部サービス利用者記法」を仮称としておく。

「異邦人記法」というのも面白いかもしれないと思ったが，一見して意味が分かりにくいので別名としてしか使えないだろう。「宛名記法」はどちらかというとメールアドレス向きか。

デライトで使う予定が全くなかったため，@[用者名] という表示は Twitter のために使うつもりだったが，これは止めておく。

そもそも SNS などでは自サービス上の用者に対する言及（メンション）という意味を持つ記法から来ている。デライトで使わなかったとしても，この種の記法を必要とするサービスにはデラングが応用出来ないことになってしまう。

ここから @[用者名] の本来の意味を考え始め，知番・輪符などと組み合わせる可能性に気付いた。これは「言及記法」として別途検討することにした。

（進捗時限記録中略）

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

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

単一文字越化

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

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

非特殊文字の扱い

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

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

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

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

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

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

数式記法との整合性

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

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

越化参照

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

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

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

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

（進捗時限記録中略）

3歩がきっかけで久しぶりに実装予定の文字装飾記法について見直し，以下のように基本的な方針を整理した。

<<大きい文字>>
>>小さい文字<<
##太字##
//斜体//
__下線__
~~打ち消し線~~

下線記法については，_下線_ を有効にすることも考えていたが，適当に書いた時の誤解釈が増える懸念もあり見送ることにした。文字装飾記法は2個以上の記号で統一した方が綺麗にまとまる。簡潔な記法は追加するより削除する方がずっと難しいので，使用頻度を考えてもいまあえて導入する動機に乏しい。

……ここまで考えて，昨年6月23日10歩でも同じ結論を出していたことに気付いたが，再確認出来た。

太字記法については，昨年6月23日9歩では ++太字++ を検討しているものの，最近 ++ を行内埋め込み記法に利用することを考えているためこれは避けたい。そもそも「強調ではない太字」という微妙な要求のための記法であり，廃案も脳裏をよぎった。

分かりやすい代替記法がありうるのかと思ったが，意外と ##太字## が悪くない。「くっきりした」という意味のシャープにもかかっているし，見た目の濃さも丁度良い。後述の文字サイズ記法同様，記号の数で濃さを調整出来ても面白い。

ついでに，<<大きい文字>>，>>小さい文字<< という文字サイズ記法を思いついた。大きさ・小ささは記号の数で調整出来てもいい。直感性は申し分ない。

あまり文字を大きくしたいと思ったことはないが，小書き括弧記法を使わずに文字を小さくしたいと思うことはたまにあったので良い拾い物だった。

斜体記法，打ち消し記法については特に変更無し。

上線記法も検討していたが，ここまでで HTML の要素に相当するものは揃い，軽標記言語としての表現力は十二分なので，いったんここで一区切りとすることにした。

今回は適当に調整するだけで済ませようと思っていた行内交度における越化だが，内容をいったん代置子に置き換え，最後に戻すという「代置子方式」を思い付き，一気に書き直した。これで越化処理が見通し良くまとまり，一つ課題が片付いた。出振るいは明日に持ち越し。

単純な手法なのでデラング整備の最初の方で思い付いてはいたのだが，まだ Dex 実装が出来て間もない時期で役割分担も未整理な所が多かったため，すっきり実装出来るイメージが湧かず，否定正規表現を利用するという方針にしていた（希哲15年7月9日1歩）。ただ，これも再考するとなかなか回りくどい。Dex 実装も十分に整理され，取り扱いにも慣れた所で，一番単純な手法に回帰することになった。

退避させる文字列配列は部区個体に持たせる形で，体系的に Dex に組み込めた。行内交度だけでなく，範囲越化が必要な場面一般に応用出来る。

Dex では，置換処理の過程で適当な目印が必要な場合に &&foo; のような疑似実体参照とでもいうべきものを使っていたが，検索上紛らわしいことがあり（通常の実体参照が部分一致するなど），論理演算子とも被るため，&_foo; に統一していくことにした。順次置換する。

ほか，パンくず記法（10歩）やキーボード記法（14歩）についての再検討でも進展，