最近，デライトでは「新生デライト」という表現を多用している。簡単に言えば，使いやすく生まれ変わったデライトのことだ。

「デライトの使い方の考え方」や「“知能増幅メモサービス”はなぜいま最も重要なのか」でも書いたように，前例のない目的を持ったデライトには，どうしても特有の難しさがある。

それでも，システムの実用化から10年以上，サービス公開から2年以上経ち，その有用性は十分に実証されている。多くの人が様々なメモツールやブログ，SNS などを行ったり来たりしながらやってきた情報蓄積・発信を，私は10年以上前からほとんどこのシステムだけで実現している。サービス公開後は，デライトでしか出来ないことを見出して使い続けてくれる利用者もいる。

“使える人には使える”ことは分かっている。残る問題は，使える人の少なさだ。そこでいま，多くの人が親しめる快適なサービスにするため，文書整備や機能整備，高速化，そして独自の軽量マークアップ言語「デラング」の整備といった包括的な改良構想を推し進めている。その完成形を「新生デライト」と呼ぶ。

順調に行って6月中，ずれ込んでも7月中には完成の見通しだ。

機能整備という点では，すでに使いこなしている利用者にとっての利便性向上はもちろん，他のメモツールなどに慣れ親しんだ初心者が戸惑いがちな機能不足を補うことを意識している。

例えば，輪郭を非公開に近い「未公開状態」に出来る公開設定機能，編集中にリンクしたい輪郭を検索出来る機能，全文検索機能，検索語提案（サジェスト）機能，ファイル添付機能，輪郭を削除する機能，自動ページ展開機能，インポート・エクスポート機能，高度なアカウント管理機能などの追加を予定している。

これまでにない密度で人の頭の中を保存するようなサービスの性質上，いわゆる非公開機能の導入は特に難しい問題だった。Apple や Google のような世界最大級の企業でも個人情報流出事件を起こしているわけで，一事業者が安全性を保証することは不可能と考えている。これに関しては，他の利用者からの閲覧を緩やかに制限する「未公開状態」の導入と，知番をファイル名として利用したローカルでのファイル管理手法を広めることで解決したい。

質問・要望も常に受け付けているので，“世界を変える”新生デライト開発にどんどん参加してほしい。

自動ページ展開機能実装が一段落した。細部に課題はあるが，実用出来る水準に達した。出振るい・手定め済み。

これに伴い，正式離立前に試していた全知検索窓や新規描出フォームの固定表示を復活させる検討も大きく進んだ。また，輪郭一覧の動的追加の仕組みを整えたことで，検索や新規描出時にも応用出来るようになった。輪郭一覧の更新が効率的に行えるようになり，高速化にも大きく貢献するだろう。

AutoPagerize 対応をどうするかというのが難しい問題だったが，これは挿入を監視して削除，注意書きを表示する方向に落ち着いた。最初以外 .autopagerize_page_element に display: none を設定しておくことで表示には影響しない。

AutoPagerize は，ウェブ利用者全体ではわずかな利用率だが，デライト用者が使っているのを見て私自身が使うようになったというのもあり，用者層の重なりは小さくない。出来るだけ混乱させないようにしたかった。

今後，広告の調整が重要になってくるため，ここで運営者・開発者向けにダミー広告を表示する仕組みを整えた（ダミー広告の様子）。

AdSense は，設置者によるクリックはもちろん無闇に表示させることも避けるべきとされているので，これまでは単に非表示にしていた。

機能的に自動ページ展開機能と似たところがある描写後略機能の実装方針検討もほぼ完了。

内容の高さが高さ制限に足りない場合どうするかが最後の課題だったが，これは舞覧側で追加取得すればいいことに気付いて解決した。

輪郭選り手抜控機能整備を概ね終え，ようやく出振るい出来た。追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが，抜控機能整備についてはここで一段落とすることにした。

この出振るいにより，中途半端な実装だった輪郭選り手抜控機能に一通りの機能が揃った。下書き抜控一覧も使えるようになり，抜控の把握が容易になった。予てから欲しかった新規描出フォームの消去・復元ボタンも抜控の削除のため追加した。18日の開発で実装した描写拡縮ボタンも使えるようになった。また，周辺の交度整理も大きく進み，理腑としての意義も大きかった。

利便性・信頼性の向上はもちろんのこと，昨年から中途半端な状態で引きずってきた当努が片付いたことによる精神衛生上の効果も大きい。昨年来の他の当努は本格的に着手していないか，着手して間もないので，ここから思考を整理しやすくなる。

抜控機能整備が長引いた最大の原因は，他にやりたいことが多過ぎたことだが，これ自体も決して簡単な作業ではなかった。ただ，この間に設計方針が変わったり深刻な不具合に気付いたりしたので，時間をかけたことで円滑に片付いた面もある。

再描出は知番でいいとして，新規描出の鍵をどうするか，というのは難しい問題の一つだった。昨年7月28日6歩から検索語を鍵に含めるようにして悪くなかったので，基本的にこれを踏襲することにした。ただし，全知検索窓から未送信の検索語まで取っていたため，これを書き換えると意図せず他の抜控を上書きしたり消去してしまう可能性があった（4月28日20歩で書いた消失不具合の原因だろう）。これは求頼文字列から取ることで回避した。

下書き抜控一覧についても，表示条件や領当てなど色々考えることが多かった。検討の結果，再描出下書きは，検索語無しの場合（上部メニュー同様）のみ輪郭一覧の上に表示（画面撮り），新規描出下書きは，他の抜控がある場合のみ新規描出フォームの上に常に表示させることにした（画面撮り）。邪魔になり過ぎない程度に気付きやすい。また，4月10日の開発で決めた通り，一覧は省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが，やはり，用合いの複雑化と抜控を溜め込み過ぎる懸念があるため見送った。抜控の溜め込みは性能低下，消失リスクの増大（あるいはそれを補う作業コストの増大）に繋がる。目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様の設計だった。一応，鍵仕様変更時の更新方法は考えていたが，手間を考えるところころ変えるわけにもいかないので，長期的視野に立って設計する必要があった。これもなんとか落とし所が見つかった。一時，鍵に仕様変更日時を含めることを考えていたが，これは複雑化を招くだけなので廃案とし，Aejs_DG_rev に判別用の文字列を入れておくことにした。新規描出下書き抜控の鍵には自我知番を含め，自我の切り替えにも対応した。

その他，これまで描写のみ保存していたのを知名にも対応する，消去ボタン・復元ボタンを実装する，などこまごまとした問題を片付ける必要があった。

出振るい後，軽微な不具合がいくつか見つかったが，一番気になったのが，鍵仕様の更新処理の失敗だった。領下で十分な手定めをしたつもりだが，本番環境では一部の鍵が1回の処理で更新出来なかった。結果的に，3回実行する必要があった。開発者通類で localStorage の内容を見ても交度を見返しても心当たりがない。

少し迷ったが，時間が経つにつれ重要性が急速に低下する部分なので，調査は打ち切ることにした。最も使用頻度の高い私や常連用者達が出振るい後も普通に使えていることから，深刻な問題は発生していないと判断した。今後，同様の処理を書く際の注意点として記憶しておく。

デライト装体調整，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歩で決めていたことだが，少し面倒臭い部分がありいまだに実現していない。

描出フォームの仕様について検討。

現状，知名欄と描写欄が離れている描出フォームの装体について，両方開いている場合は合体させることにした。

美観上の問題も感じており，この案自体は当初からあったが，もともと両欄は個別に開けるようにしていたため，挙動との整合性などを考えると難しい問題だった。

個別に開ける仕様自体は，閲覧模動・編集模動の区別を明確にしつつ，出来るだけ操作感を WYSIWYG に近付けたいという考えから編み出したもので，作業対象が絞り込みやすいこともあり維持したい。

少しずつ実装が変わり，最近では両欄が開いている時は一つの選り手とみなすようになっているため，合体させても違和感がなく，中止ボタンの導入などを考えるとむしろ合体していた方が直感に適う。

これに関連して，中景部で中景輪符・描写部以外の部分を [Ctrl] + ダブルクリックして両欄を開くようにすることにした。これ以前から最近考えていたことだが，丁度良い。

現状，同操作は中景輪符・描写部に対してのみ有効で，中景部の他の部分では反応しなかった。これは直感に反する挙動でもあり，描写部が空の場合の代置語を削除した最近の実装では同操作で描写欄が開けないといった実用上の問題もあった。

一日，ほぼデラング整備で終わった。

ひとまず交度対応を目指し，デラング換配系の現実解として構想が出来つつあった「Dex」の実装に入る。

一日の終わりには見事に Dex_T として基礎的な構造化に成功，デラングにとって大きな足掛かりが出来た。

最小限の機能でなかなか拡張出来ずにいたデラングも，今後は自由自在に拡張出来るだろう。現実解のつもりで始めたが，出来てみると最適解，まさに〈dexterity〉という感じだった。これまで余計な手を加えなかったことすら大正解に思えてくる。

装体調整でも，稲妻形引用部区の完成（3歩），微妙に難しい問題だった交度部区のカラーテーマが決まる（11歩）など小さくない収穫があった。