詰め込んだ雑務もなんとか片付き，今月も結局上手く乗り切れてしまった。これで来月からは時間的なゆとりも出来る。

デライト宣伝については，まず「ツイスト回帰」で様子を見ることにした。デライトの蓄積にならないことを極力避ける。

最近，他人に対する興味の無さについてよく考えている。つくづく，自分は他人に興味が無いのだと感じさせられることが増えた。例えば，デラングの引用記法にしても，自分であまりにも使わないので，他用者の使用頻度に驚くことがある。世間の話題は一応追っているが，共感出来ることがあまりにも少ない。どうしても退屈さを感じてしまう。

Twitter 買収騒動にしても，10年以上前から KNS を構想していた私からすれば，まだ Twitter で時間が止まっているのか，という感想だったが，現実に世間が注目するのも大金が動くのもそんな Twitter だ。はるかに革新的なデライトの方ではない。いま世間が求めているのは Twitter 程度のものなのだと思うと時代の壁を感じざるをえない。

この性格は，新しいものを作ることには向いていても，新しいものを広めるとか，広まるように作るということにはやはり向いていないのかもしれない。自分と世間の関心が重ならないのだから。もちろん，なんとかするしかないのだが。

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

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

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

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

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

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

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

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

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

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

長い間課題だった描写拡縮ボタン，輪郭複製機能について大きな進展があった。

描写拡縮ボタン

昨日の開発で最大化アイコンが出来たことをきっかけに，描写拡縮ボタンの実装イメージが固まり，実装・手定めまで概ね完了した。想像以上に早く上手くまとまった。下見機能との相性も良い。ただし輪郭選り手抜控機能整備が途中であるため未出振るい。

• 描写拡大ボタンの様子・初期状態
• 描写拡大ボタンの様子・スクロール途中
• 描写拡大ボタンの様子・スクロール完了
• 描写拡大ボタンの様子・暗い背景色
• 描写縮小ボタンの様子

描写拡縮は機能的には単純だが，用合い，特に領当てが難しかった。最近，描写部下境界に重ねる形での実装を考えていたが，描写部を飛び出すと他の要素に干渉してしまう。かといって余白を無駄に広げたくない。これは，下部の陰影に重ねつつ，初期化時点でスクロール可能な場合は下余白を追加することで解決した。文字や暗い背景色と重なっても視認出来るように，半透明の白背景を付けた。

拡大ボタンはスクロール可能であることの目印としても効果的なので，これを活かして，スクロール完了時には透明度を上げ，それと分かるようにした。

これで，外観・操作感ともにデライトに調和した描写拡縮ボタンが出来た。描写部の高さ固定は一覧性を確保するために必要なものだったが，用合い上の弊害も小さくなかった。陰影付きスクロール，最大化アイコン，そして描写拡縮ボタンによって，ようやくこの問題が解決した。

編注記法，範囲越化記法についての検討で終了。

最近，編注記法も多用するようになっているため，C 式の / ... / 対応に向けて本格的な検討を始めた。HTML 式の <!– ... –> は入力効率に若干難がある。

C 式込め言と絡めて \ ... \ のような形で範囲越化記法が出来ないか考えていたが，これは 自体の越化と紛らわしいという問題があった。これに関しては，\ ... \* という記法が使えそうなことに気付いた。

による単一行込め言は，斜体記法と紛らわしい。https:// などにも含まれるし，日本語では感情表現にも用いられる。使用頻度はそう高くないはずなので，あえて導入しないか，判定条件を厳しくするか，別の記法を考えるか。* がいいかもしれない。

（進捗時限記録中略）

昨日，寝る直前にまた脳爆発があり，今朝にかけて文字装飾記法とタグ記法周りの概念整理・仕様整理が急速に進んだ。

文字装飾記法は，「文字装飾を伴う慣用表現」のための記法と位置付けることにした。太字記法（##），斜体記法（//），下線記法（__），打ち消し線記法（~~，翌日のまとめで「打ち消し記法」から改称）の4記法を基本とし，それぞれ所定装体（スタイル）を伴う <b>，<i>，<u>，<s> HTML 要素に対応する。

@ を使った文字サイズ記法，% を使った色記法も検討していたが，タグ記法の概念が出来たことで中途半端なものになるため，これは廃案とする。

文字装飾記法はこれがほぼ完成形か。

検討過程

3つの検討方針

実装自体は容易な部類で，記法も概ね固まっていたにもかかわらず文字装飾記法の実装に踏み切れなかった理由として意味論的な問題があり，これが思いのほか難題だった。実装方針は3通り考えられる。

1. 完全に意味論的な記法にする
2. 完全に装飾的な記法にする
3. 意味論と装飾を重ね合わせた記法にする

（進捗時限記録中略）

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

昨日の調整後，描写内見出しで5階層分の装体を用意すると中景輪符が <h2> から始まる場合に第5階層以下の見出し装体が変わってしまうことに気付き再調整（再修正後の画面撮り）。

最終的に，見出し装体は4階層分あれば十分かつ最適と結論付けた。実際には第3階層を使うことも稀だ。

見出し記法の階層の深さに制限は無いが，装体の表現の幅は有限なので，滅多に使わない下位見出しまで考慮すると使用頻度の高い上位見出しの表現の幅が狭まってしまう。

4階層なら丁度4種類の下線でまとまる。第5階層がほとんど単なる太字になっていたので中途半端だった。文字サイズも，分かりやすく 1.3em，1.2em，1.1em，1em と0.1em刻みに出来，しっかりメリハリがついた。

0.05em刻みは Chrome では意図通りに表示されたが，何故か Firefox と Safari の通常倍率表示では 1.1em と 1.15em の違いだけが全く分からないという問題もあった。

<h6> 相当以下の見出し記法は全て <h6> になる仕様は据え置くつもりだったが，これは階層関係の観点から再考する必要があるかもしれない。<p.heading> にしている pandoc のようにすべきか。結局横並びになるなら同じな気もする。

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

見分けにくかった見出し装体の視認性が大きく向上した（修正前・修正後）。

見出し装体の固定化

まず，これまで中景輪符が <h1> で始まるか <h2> で始まる（前後景輪一覧）かで描写内の見出し装体も1階層ずつずれていたが，これはいったん固定することにした。

ずれるのも HTML の文書構造からみれば間違った表現ではなく，中景輪符の表現も少し変えるべきかと考えていたが，これもなかなか難しい。中景輪符の知名部は，現状 <h1> でも <h2> でも font-size: 1.4em，font-weight: bold，letter-spacing: 0.05em という装体になっている。輪郭という情報単位の粒度を考えた時，これ以下は小さ過ぎ，これ以上は大き過ぎという所だ。

他の要素も，要素同士の対比を考えて細かく装体を調整しているため，それらまで見出し装体の変化に合わせると保守性に悪影響を及ぼす。将来的にどうかはともかく，現時点でそこまでする利点は無いだろう。

CSS では h1 ~ .dln h2, h2 ~ .dln h3 のように兄弟結合子を使えば簡単に実装出来る。

装体調整

あくまでも描写内での見出し階層で装体を固定することにした上で，第1階層から第4階層までの描写内見出しには二本線・一本線・破線・点線と4種類の下線を付けることにした。これまでは第1階層に2px，第2階層に1pxの一本下線のみだった。

二本線は border-style の double では制御しにくいため ::after を使い，1pxの線に2pxの間隔をあけた。また，点線も舞覧によって破線より目立ってしまう場合があるため，色を調整することにした。

最初は，第1階層の二本線，第2階層の一本線があれば十分かと思ったが，結局文字サイズだけの変化ではぱっと見分かりにくい。各描写内見出しに図形的な特徴があった方が良い。

文字サイズは，これまで 1.3em，1.2em，1.1em，1.05em，1em だったのを 1.3em，1.2em，1.15em，1.1em，1.05em とした。

1.3em から 1.1em まで0.05em刻みの方が数字的には綺麗かと思ったが，下線で特徴を付けても，特に第1階層と第2階層が一見して見分けにくかった（画面撮り）。それ以下は使用頻度も低いので0.05em刻みでも大きな問題はないだろう。

letter-spacing や font-weight の調整余地はもう少しありそうだが，視認性の改善という目的は十二分に果したのでここで一段落とした。

2pxの一本線よりも1pxの二本線の方がすっきりした印象になるのが意外だった。

（進捗時限記録中略）

3歩がきっかけで久しぶりに実装予定の文字装飾記法について見直し，以下のように基本的な方針を整理した。

<<大きい文字>>
>>小さい文字<<
##太字##
//斜体//
__下線__
~~打ち消し線~~

下線記法については，_下線_ を有効にすることも考えていたが，適当に書いた時の誤解釈が増える懸念もあり見送ることにした。文字装飾記法は2個以上の記号で統一した方が綺麗にまとまる。簡潔な記法は追加するより削除する方がずっと難しいので，使用頻度を考えてもいまあえて導入する動機に乏しい。

……ここまで考えて，昨年6月23日10歩でも同じ結論を出していたことに気付いたが，再確認出来た。

VirtualBox の設定調整などで終了。

これから仮想機の使用頻度が上がりそうなので，VirtualBox を最新版（6.1.30）に更新，少し設定を整えた。

動作は多少軽快になった気がするが，元々あったリサイズ周りの癖がひどくなった。dwm との相性の問題かと思い config.h を弄ってみたが，フローティング対象に WM_CLASS の VirtualBox Manager は効くのに肝心の VirtualBox Machine が効かない。

環境設定 → ディスプレイ のヒントで指定しても駄目，VBoxManage で設定しても駄目だった。慣れでなんとかなる問題ではあるのでしばらく様子見。

譜類整理で終了。

久しぶりに外付け HDD を覗いた。古いものだが，使用頻度は低かったので整理すればまだ使えるだろう。

昔の抜控が色々残っているので考古学的な面白さもある。