デライト高速化，KNEST 隠し実装，輪数取得改良。

良い機会なので，長らく未実装だった描出・輪括関連の外充て函数もここで実装してしまうことにした。作業範囲は広がったが，保守性・効率性の向上はそれなりに見込める。

第二次知番改良，第零番節の削除。

交度・出場の整理は概ね終え，手定め環境での基本的な動作も問題ない。本番環境での作業手順も概ねまとまった。出場の見通しは非常に良くなった。

ただ，一点，dg_kno_vac() の修正で詰まった。ここだけ不自然なほど雑な交度になっている。一昨年8月にすぐ見直すつもりで離れ，そのまま放置していた。頭の片隅でずっと気にはなっていた。

今日中に準備を完了して明日早朝出振るいをするつもりだったが，ここはしっかり見直すべきと判断。出振るいは明後日早朝に持ち越す。

別の収穫として，「輪数取得改良」の方針が概ねまとまった。更なる高速化が見込める。

（進捗時限記録中略）

対 Markdown 戦略についての9歩の検討を踏まえて，Cμ 文字列処理改良を終えた後は，こまごまとした記法関連の調整を片付け，描写渡括（描写埋め込み）の実験的実装に入ることにした。最もデラングの「目玉」になる可能性がある。

実装そのものはさほど難しくないものの，負荷への懸念から KNEST 隠し実装の後かと思っていたが，Cμ 文字列処理改良でも相当な高速化が見込めるようになったので，輪郭情報の一括取得，1輪あたりの埋め込み回数の制限など基本的な最適化・負荷対策で何とかなるかもしれない。

（進捗時限記録中略）

Cμ 文字列処理改良，rgx_T の置換道手の引数順序変更。

作業方針の再検討で終了。

あとは rgx_T::rpl() の引数順序変更で rgx_T の置換道手の引数順序変更は完了だが，これまでの道手の呼び出し箇所が Dex のごく一部に限られていたのに対し，.rpl() は Cμ 初期からあちこちで使っている置換道手なので，少し複雑な作業になる。

まず，いったん .rpl() を適当な名前に変えて無効化し，呼び出し箇所を引数順序変更済みの .rpl_glb() あるいは客体表現に置換するか，正規表現・客体表現を使うまでもない処理なら s_T の補助函数に置換する。現時点で .rpl_glb() は .rpl() の冗長版に過ぎないため，置換したままにしておいて問題ない。交度整理をしていけば自然に戻るはずなので，あえて再置換はしないことにした。

置換作業に入る前に，作業に必要な s_T の補助函数整備も必要だが，既存の「類型化正規表現」（rgx_x_T）の置換道手も旧式の引数順序にならっているため，まず最初に客体表現（ojx_x_T）への書き換え作業を済ませることにした。rgx_T を直接使った交度から類型化正規表現への書き換え作業が想定より遅滞していたことが幸いして，現時点で類型化正規表現は多くない。

いずれにせよ，正規表現の総点検や客体表現への書き換えが必要な時期であり，保守性と効率性の大きな向上が見込める良い機会だ。

「換配確認機能」についての再検討で終了。なお，この検討から「下見（プレビュー）機能」に改称した。

下見機能は，輪郭選り手左下に下見ボタンを置く形でほぼ確定か。

デラング整備の進展とともに重要性が増している下見機能だが，用合いをどうするかについてはまだ少し迷いがあった。

一応の最有力案は，輪郭選り手左下に「確認ボタン」を置くというものだった。左上は公開設定機能，右上は取り消しボタンに使いたいので，左下に置くのが自然ではある。

完了ボタンと並べるという案も捨て切れなかったが，押し間違いが多発しそうで用合いとしては難がある。

今朝ふと，確認ボタンから描き出し・完了ボタンへの二段階方式が浮上してきた。つまり，必ず換配確認をしてから描き出し・描き直しを行うことになる。

二段階方式の利点には用合いの単純化や初心者にとっての流れの分かりやすさ，おまけに捌き手の負荷軽減も見込めるが，使い慣れた用者にとっては煩雑になり過ぎる懸念があり，採用は見送った。

ある程度複雑なデラング記法を使う場合など換配確認をしたいこともなくはないが，確認するまでもない描き直しも多々ある。また，公開設定機能の導入によって気軽に描き出し・描き直しが出来るようになると，役割が重複してしまう。

一つ，輪郭削除の確認機能を兼ねられるかとも思ったが，そもそも知名・描写を空にして削除というのが確認作業も兼ねているためこれもやはり煩わしい。

やはり，換配確認は選択的な機能にしておくべきだろう。

これまで，完了ボタンに近い位置に置くことも考えていたため，描出の流れの中で分かりやすいように「確認ボタン」「換配確認機能」などと「確認」をプレビューの日本語表現として採用していたが，ある程度独立した機能として認識しやすいように今後は「下見」とすることにした。

キーボード記法の改良で終了。

従来の二重角括弧を使った [[X]] 記法に加え，アンダースコアを組み合わせた [_X_] 記法を使えるようにした。

旧記法は近いうちに廃止し，ウィキ互換の輪結記法に転用する。ハッシュタグ同様，単純に全知検索に飛ばすだけだが，他サービスからの移行者がデライトに触りやすくなったり，デライト向けに文書を書き直しやすくする効果が見込める。

大きな用途の変更であるため，時印によって適用版存を切り替えることになりそうだ。

11日14歩の検討で方向性は定まっていた。旧記法を導入した昨年3月11日はまだデラング整備の最初期で，あまり他サービス・他言語との互換性は重視しておらず，他サービスで採用例の多かった二重角括弧による輪結をキーボード記法に使うことも，独自性を出すのに良いだろうという程度にしか考えていなかった。

最近のデラングが，デライトにとっての利益を損なわない限り他サービス・他言語との互換性を最大化するという方針になっていることに加え，単純に旧記法の視認性の悪さが気になっていたこともあった。最近ではほとんど自分で使っていなかった。

[[Ctrl]] のようにキー名に長さがあればまだいいが，[[X]] では流石に記号が邪魔臭い。[_X_] という記法は当時検討した記憶があるが，[X] に対して物足りず決め手に欠けると感じたか，なんとなく見送っていた。[[X]] は「キーの立体感を表現しているように見えなくもない」（希哲15年3月11日2歩）と思っていたが，<kbd> の装体はデライトも含めて，四方を線で囲み，立体感を出すため上境界線よりも下境界線を目立たせるという形になることが多いため [_X_] の方がむしろ装体に近い。

逆括点を使った [`X`] という記法の採用例を見かけて悪くないと思ったが，まだ普及度も低い上，これは `[X]` との書き間違いが続出しそうだと感じたたため見送った。[_X_] ならその問題もなく，直感性でこれに勝るものはなさそうだ。

<kbd> は入れ子にすることも出来るので，[_Ctrl_] + [_X_] のような組み合わせも記法として扱うことを考えたが，実用上大きな変化はないはずなので後回し。

昨日は開発環境整備の一環として消極的に考えていた SLFS 開発の再開だが，献典整備としての可能性もあることに気付き，新生デライト開発とともに再開することを決めた。

当然ながら無駄に新生デライト開発を圧迫するわけにはいかないので，相乗効果を生み出すようにやっていきたい。

SLFS は希哲11年に実用化してから，あえて深追いすることを避けてきた。ほとんどは実用上の問題が生じた時に設定やパッケージの引装などを行うくらいで，それも SLFS 開発というよりは用者として使っているという感覚であり，事実上の開発停止状態に近かった。

直接収益化に結び付けるのは極めて困難と予想されたため，パッケージの下信（ダウンロード）や引装（インストール），手定めにかかる時間を最小化するための極力良いネット環境と高性能な開発機，そして十分な時間を用意する必要があると考えていた。

SLFS は希哲社にとっても大きな財産だったが，自分で使っているだけということに「死蔵」というべきもったいなさを常々感じていた。時間の経過とともに忘れていることも増え，保守性も落ちていた。これを改めて実感したのが昨日の核脳（カーネル）周りの調査だった。

SLFS 開発から遠ざかるようになっておよそ一年後，デライト開発に入り，デラングも含めて描出環境も描出手法も飛躍的な発展を遂げ今にいたる。希哲11年に比べ，技術記録もはるかに描き出しやすくなっている。金風によって多少の時間的余裕も出来た。

こうした環境の変化によって，気付けば十分な時間対効果が見込めるようになっている。SLFS にもようやく世に出せる時が来たということだろう。新生デライト開発の再開前に何かが引っかかっていたが，この時を待っていたのかもしれない。それなら遅らせた意義もある。

昨日に続き5時前起床は出来たが，短時間睡眠続きなので早く寝ることにした。

（28日の振り返り日記）

主にデライト高速化，違了処理整備。

Aejs の整理をしつつ，前縁の違了処理実装を大方終えた。

ついでに，崩れていた問題発生ページ，保守作業中ページを整え直し，出振るい作業などに再び活用出来るようにした（19歩）。

これらの作業により，用者・検索演心への影響を最小限に抑えながら後縁に手を入れることが出来るようになり，信頼性・開発効率の大きな向上が見込める。

後回しにしてきた課題だったが，デラング整備に加えてデライト高速化まで活発化している今，後縁の出振るい頻度が高まり，それに伴う不具合の増加・多様化も予想されるため，ここで解決しておきたかった。

Cμ 基礎改良，文字列処理改良の方針検討。

現状，Cμ では文字列・整数間変換にストリームを利用しているが，これを strtol() と snprintf() による実装で置換することにした。

Cμ 最初期からの実装だが，呼び出し回数も高が知れていた当時と比べ，依存交度も巨大化している今なら相当な効果が見込める。