（進捗時限記録中略）

輪郭ページ改良と装体調整で終了。

取り急ぎテンプレートを整理して，輪郭ページの吊るし輪郭を入れていた要素を <header> から <main> へ，輪郭ページの輪郭一覧を <main> から <div> に切り替えた。前後景一覧ページでは従来通り。

特に急ぎたかった部分が上手く片付き，残るは内部的な問題のみなので，輪郭ページ改良はここで中断することにした。

閲覧専用模動の実験をしていた時，輪郭ページの輪郭一覧を隠すと <header> だけのページになってしまうことに気付いたのが事の発端だった（15日14歩）。

あまり意識してこなかったが，輪郭ページの概念と実装に大きな不一致が生じていた。一時凌ぎのつもりで後景一覧ページを輪郭ページに使うようにしたのはデライト離立補完中の希哲14年8月5日だった。当時と今とでは輪郭ページの捉え方も輪郭の充実度も全く違う。

予てから検索模動・輪郭模動の内部的な切り分けが中途半端なまま進んでいない問題もあったため，抜本的な輪郭ページ改良の方針をまとめた（17日8歩）。

最近の検索演心はそこまで神経質ではないと言っても，<header> と <main> の違いは流石に小さくないだろう。何より，気付いてしまうと表現として気持ち悪いので早く解決したかった。

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

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

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

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

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

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

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

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

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

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

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

出振るい済み。

自動リサイズ機能

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

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

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

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

字数計

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

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

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

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

（進捗時限記録中略）

ひょんなことから，予てからの課題だった折り畳み記法が急速にまとまった。

折り畳み記法は，他の部区記法と組み合わせて使える汎用的な記法として実装していくことにした。以下のように，部区の開始行末に ^ を加えることで，その部区（見出しなら階層下の内容）が折り畳まれるようにする。厳密に言えば見出しは階層下の内容を含む部区ではないが，例外的に扱う。

・リストの折り畳み ^
  ・折り畳まれる項目

* 折り畳む見出し ^
折り畳まれる内容

+{埋め込みの折り畳み K#XXXX} ^

検討中，これがネタバレや NSFW のような閲覧注意の内容に使えそうなことにも気付いた。

きっかけからまとまるまで

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

雑多な考え事。

SLFS の起動管理系を整えたことで，そろそろ画面管理系も欲しくなってきた。規模的に早期独自実装も視野に入る。

知機における自我認証に PAM の採用を検討。画面管理系について考えていたところで気付いた。

現状の輪郭選り手の問題として，文章においても部分編集がしにくいという問題があり，用者からも指摘されている。

予てから問題だとは思いつつ，その感覚的な問題らしさに反して，かなりの長文も書いてきた私があまり困ったことがないのが不思議だった。よく考えてみると，長文であればあるほど誤字脱字や気になる箇所が増えるし，まず修正箇所が一点に収まることがないので，結局，最初からざっと点検しつつあちこち修正する，という作業をしていることが多い。こういう修正の仕方だと，最初から全体を選り手で開いてしまった方が無駄な表示の切り替えなどがなく，かえって効率的とも言える。

とはいえ，こればかりは書き手の癖によるところが大きく，手段が多いに越したことはないので，部品単位編集の一種として段落毎の編集を可能にするなどで対応することになるだろう。

自我知番のみの輪符に対応。

（特に Firefox の）舞覧隠しが思うように効いてくれない問題についての調査，検証。予てからの課題だったが，なぜか写真の WebP だけ隠しが効かず，写真整理の障害になりそうだった。

いまだに規則性は掴めていないが，色々弄っていたらだいぶ改善した気がする。たまに不可解な隠しの不使用があるものの，概ね期待通りに隠しが効いてくれるようになった。

Vary あたりが怪しい。