第二次知番改良，ここから自我知番省略機能実装に入る。

作業方針検討で終了。

最近，K#/XXXX 形式の知番は一律自自我の省略とみなし，知番実装に自我知番省略機能を組み込んでしまうことまで考えていたが，これはやめておくことにした。自輪郭内や自輪郭検索など文脈から明らかな場合のみ自自我の省略とみなす。とりあえずは，前縁，デラングや全知検索など，部分的な対応から始める。

将来的に知番が長くなった場合，例えば K#-XXXX や K#/-XXXX のように知番の一部で絞り込みが出来るようにしたい。知名と組み合わせれば十分なことも多いだろう。K#/XXXX もその一種として扱えた方が理解しやすい，と考えると一定の柔軟性を残しておきたい。現状，そこまで長い知番は多くないので，これは「知番略記法」として第三次知番改良の課題にする。

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

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

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

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

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

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

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

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

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

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

またまた就寝前に良い思い付きがあった。

抜控一覧は，省略せず，全て表示させることにした。

一定件数以上は省略するように考えていたが，良い用合いが難しかった。そもそも，抜控機能にあまり依存してほしくないとも考えていたので，邪魔で丁度良いことに気付いた。

AdSense が端末回転に上手く追従しないという不具合に対応。とりあえず，overflow: hidden で対応した。

通常は推奨されない方法だが，ごく限定的な状況への対応であることに加え，「それが収められているフィード コンテナの幅と常に同じ」と説明されているインフィード広告の不具合とも言えるので，AdSense の趣旨に反するものではないと判断した。

（進捗時限記録前略）

描写内 <code>，<kbd> の装体調整で終了。これまで適当にしていた高さと垂直位置を調整した。

特に，輪結の下線と枠が被っているのが気になっていたので直したかったが，意外に正確な調整が難しく，かなり試行錯誤した。

最終的に，<code> と <kbd> は position: relative;display: inline-block にし，下線との隙間は bottom で調整することにした。あとは height，line-height，padding で微調整を繰り返し，ようやくどの舞覧で見ても大きな問題はないようになった。

舞覧毎に僅かな癖は残るが，だいぶマシになったのでとりあえずここで区切る。課題は残ったので暇をみてまた調整していく。

• 途中で不自然に改行されてしまう問題も行内部区になったことで解消した。
  • 折り返しは禁止し，長過ぎる場合は省略させようかと思ったが，overflow: hidden や overflow: clip を指定した時点で舞覧間で縦位置が揃わなくなるため保留。
• <a> の padding-bottom での調整は断念。ルビとの相性が悪く，行間も現状の line-height: 1.8 は変えにくい。
• Edge では他の舞覧のように下線の位置が下がらないため相変わらず被っている。

（進捗時限記録中略）

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

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

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

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

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

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

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