（進捗時限記録中略）

今後の Dex 設計方針についての検討で終了。これから越化参照が大活躍しそうだ。

まず，課題だった脚注記法の実装方針について検討している内に，越化参照が部区間通信に活用出来ることに気付いた。

部区毎に越化条件の変化などがあることから，各記法の解釈は部区個体に任せたい。しかし，脚注記法のように最上位部区との出与え共有が必要な記法もある。

このような場合，単純に考えれば指示体を通して部区個体間で変数を共有するということになるが，この種の記法が増えるたびに目的別の指示体を増やすのは設計として美しくない。汎用的な変数一つに集約するのも，効率性や厳密性の観点から難がある。

ここでふと，越化参照が使えることに気付いた。下位の部区個体で中途解釈した記法には目印となる越化参照を付け，上位の部区個体で変換処理を完了させる。

これに似た部区間通信の手法は Dex 初期実装から現 &_skp; で使い続けているが，どちらかというと「邪道」だと感じていたため，意図的に応用範囲を広げなかった。紆余曲折を経て，これが一番単純性・効率性・保守性のバランスが良いということが分かった。

これで脚注記法や目次記法の実装は容易になった。他にも，輪郭情報の参照が必要な記法など，部区間通信が必要な場面全般で越化参照が活用出来るだろう。

もう一つ，処理済み対象の識別に関しても進展があった。

1月21日4歩で，&_tgt; や &_fin; のような目印を付加することを考えていたが，付加的な越化参照では結局正規表現の複雑化が避けられないため，実用化出来ていなかった。

昨日終えた客体表現への書き換えで Dex 初期実装の交度を整理している時，再置換を避けるため記法の一部を越化参照（当時の疑似実体参照）に置換する手法を使っていたことを思い出した。これもあまり積極的に応用範囲を広げなかった手法だが，思っていたより合理的であることに気付いた。

例えば，http は &_http; のように一時的に置換してしまえばいい。考えてみれば単純なことだが，灯台下暗しのごとく単純なことの真価を理解するには時間がかかるということを改めて学んだ。経験不足だと，どうしてもより高度そうなことに目移りしてしまう。

面白いことに，どちらも原点回帰のような発見だった。

直感で編み出した Dex 初期実装の手法を再評価する十分な経験が出来たこともあるが，「越化参照」という概念が完成し，積極的な活用を考えられるようになったことも大きいのだろう。中途半端だった「疑似実体参照」から発展したのはつい先月のことだ。

デライト装体調整，URL 装体調整で終了。

直書き URL（<a.URI>）を font-size: 0.9em の等幅フォントにした（URL 装体調整前後）。字間無しは昨年6月30日の開発からだが維持する。

直書き URL のある描写が読みにくい問題はずっと以前から感じていて，何度か調整しているが，一昨日の開発中にふと，「文字サイズを小さくしていない」ことに気付いた。

昨年6月30日の開発で字間無しにしているが，等幅フォントにして変に目立ち過ぎるという理由で戻したりもしている。この時になぜ文字サイズを小さくするという発想がなかったのか不思議だ。他にも問題が山積していて思考時間が割けず，灯台の下まで目が行かなかったか。

今回は <kbd> や <code> の装体について考えていたところだったので，その関連で気付けたのだろう。

文字サイズはやはり0.9emが丁度良い。0.8emにすると長い URL はともかく短い URL を提示する時に今度は目立たな過ぎる。

これにより，十分凝縮されメリハリが付いたので，予てから検討していた長い URL の省略については保留とすることにした。

長い URL の省略は，簡単なようでいざ導入しようとすると意外と難しい問題がある。

まず，デライト上の文書の傾向からいっても，「ちょっと長い」程度の URL は省略したくない。URL の全体が情報として有用な場合がしばしばある。このあたりはマイクロブログなどとは事情が異なる。

では，どこで省略すべきかという問題になるが，長い URL を許容すればするほど比較的短い URL の読みにくさが解消されないというジレンマがあった。これは装体の調整で解決した。

そもそも輪結記法（[ ... ]）もあるので，現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx のような省略記法を導入してもいい。

ただ，パーセント符号化の復号はしたい。これは昨年3月22日2歩で決めていたことだが，少し面倒臭い部分がありいまだに実現していない。

思いがけず，強調輪符と輪結装体の仕様が整理された。デルン最初期からの課題であった輪符の見せ方に大きな進展となった。

昨日分のまとめをしている時，ふと思いつきから作業を始めた。最初はすぐに終わると思っていたが，作業が一段落したのが9歩，まとめ終わったのが19歩と，次第に事の重大さに気付いていった。デルンにとって基礎中の基礎である輪符だが，「灯台下暗し」になっていたのかもしれない。

ごく単純な解決策で，大きな実装コストがかかると分かっていながらまだ捨て切れていなかった自動装体路線を捨てられたという意味でも極めて大きな収穫と言える。

昨日の日記を付けながら，デライト累新は希哲館累新でもあり，「千年の集約」でいうところの累新に，希哲館黄金期は近代化の過程に相当することに気付いた。

最近，こんなことをぼんやり考えながら時が過ぎてしまうことが多い。脳がよほど情報を整理しようとしているのか，少し思考に引っかかりを感じて手を止めると，そのまま何時間も経っていたりする。そのせいで開発も少し停滞気味だ。

経験上，こういう時は「待つ」以外にこれといった対処法が無いことは分かっているが，流石にそろそろ手を動かしたい。

そう思いながら，デライト公式で希哲館訳語についてのツイストを書いていた。相変わらず，独自性という言葉も陳腐に感じるほどの異形ぶりに，自分は日本の中心部にありながらどんな環境で育ってきたのだろうと改めて感じていた。

あるツイストを書き終えた瞬間、なぜか，幼少期にかくれんぼで大人達を困らせた記憶が蘇えってきた。希哲館事業というのは，自分にとってずっとそんな「わくわく」する悪戯だったのかもしれない。一夜革命なんて，やたら壮大なだけでまさにかくれんぼではないか。久しぶりに「三つ子の魂百まで」という言葉を思い出した。

急に童心にかえったような気分になり，すっと肩の力が抜けてなんだか笑えてきた。

気付いてみればこんな単純なことに今まで気付かなかったのか，気付いたことを忘れているのか，灯台下暗しということもあるから分からないが，変に嬉しい発見だった。

これだから思索はやめられないのだろう。

今日は前後景輪の一覧実装を始める予定だったが，深刻な不具合などに気を取られ準備程度のことしか出来なかった。

しかし，交度を整理しながら描写選り手周りの改良をよく進めることが出来た。特に，描き直しの挙動はこれまで自分で気に入らないところだったので，洗練されたのが嬉しかった。

以前から怪しかった AdSense と Aejs の干渉問題も根本的な解決策を施すことが出来た。

昨日の開発記録をまとめていて，公開連絡先を使った新しい暗証語忘れ対策を思いつき，この方向でまとめていくことにした。

もう一つ大きな作業方針上の進展として，自我登録時の知番予約改良を一括挿入（バルクインサート）から試すことにした。初歩的なことだが，余裕がなかったのか Cμ と外充て函数を過信していたのだろう。これも灯台下暗しだった。ずっと非同期化の方向で検討していたが，そもそも非同期化しないと困るような処理が自我登録のたびに走っていたら捌き手がもたない，かといって予約範囲の分割も煩雑化を招く，といった懸念があったため，これで済めば万々歳だ。

その他，Twitter Publish と + 記法を使ってツイート埋め込みをする方法について検討など。

デライトの諸場用合いで最大の課題だった引き入れの操作性だが，ふと，旧全知検索で実装していた引き入れボタンを思い出した。

引き放ち（ドラッグ＆ドロップ）式を重視したデライトの新全知検索に移行する過程で消えたが，スマートフォンなどの諸場用合いで快適に引き入れするにはこれしか無さそうだ。ちょうど前後景輪一覧を整備しようとしているところなので，引き入れボタンを改良して復活させ，諸場用合いではこれを推奨する方針をまとめた。

当初は引き放ち式にとらわれ過ぎていて灯台下暗しになっていた。その後，写し貼り式に焦点を移すが，試してみるとこれも諸場では煩わしいことに気付き，しばらく出口が見えない状態が続いていた。結局原点回帰になった。