脳爆発のおかげで検討作業では大きな収穫があったが，思考が広がり過ぎたか。サイクリングでそれなりに身体を動かしたにもかかわらず，夜は脳疲労感が強かった。他にちょっとした幸運があり，少し気が緩んだことも影響しているかもしれない。

最近，ちょくちょく「KNS の経済的合理性」について考えている。考えれば考えるほど，KNS は SNS と PKMS の相補的・相乗的な発展形であると同時に，経済的合理性において唯一の解だと思えてくる。

SNS の経済的な問題は，「献典の質」にある。開放的にして人を集めると，どうしても粗悪な献典が増える。そもそも，SNS における投稿は体験のための手段に過ぎないことが多く，献典としての情報価値が低い。

日常的な挨拶から「バルス祭り」まで，情報としての意味はない出与えを抱え過ぎている。砂金のために土砂を全部保管しているようなものだ。意味がないだけならともかく，不法行為やデマのようなものも誘発する構造を持っているのも厄介だ。放っておけば広告主が減るし，監視を強めれば人件費が増える。かつての匿名掲示板も同じ問題を抱えていたが，文字という最も軽量な情報が主でありながら維持費に収益が追いつかない理由だ。

他方の PKMS では，知的関心で献典が蓄積され，利用者も自然と内省的になるので献典の質や治安は総じて良い。

ただ，PKMS はとにかく「高コスト体質」になる。今まともに開発しようとすれば，厳重な制危と情報保護体制，複雑な WYSIWYG 選り手，自動保存，編集履歴，オフライン対応，ゆとりのある譜類上信機能あたりは基本として，OCR や人工知能くらい付いているのも当たり前になりつつある。デライトがこれらの機能を上手く切り捨てられているのは，やはり KNS という根想によるところが大きい。どれも SNS なら必要性が低い。

しかも，PKMS は閉鎖的なサービスなので収益化手段は限られ広告宣伝費もまともにかかる。Evernote にせよ Notion にせよ，SNS に比べると規模的には伸び悩みの状況にある。

そこで KNS たるデライトの出番というわけだが，KNS は KNS で「新し過ぎて理解してもらうのが難しい」という問題を抱えている。逆に言えば，ここさえ突破すれば SNS の次と PKMS の次を同時に創出出来る。SNS をメモ通類として使っている人，PKMS を情報発信に使いたい人はそれなりにいるので，突破口は確実にある。

これが目下デライトの闘いだ。

（15日の振り返り日記）

昨日の見出し記法不具合修正の間違いに気付いたたため再修正。出振るい・手定め済み。

見出し階層を上げる処理が基準階層から記号の数だけ階層を下げるという回りくどいものになっている理由を昨日は思い出せなかったが，見出し階層を下げる処理と異なり中間を飛ばせる処理に対応するためのものだったことを思い出した。昨日の修正では記号の数にかかわらず1階層しか上げられなくなってしまう。

とりあえず，原則として，前の見出し記号の数から減らした記号の数だけ階層を上げるようにした。

（進捗時限記録中略）

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

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

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

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

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

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

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

（進捗時限記録中略）

新生デライトの要件ではなかったが，デライト最初期に実装・削除してからずっと保留状態にあった全知検索窓固定機能の実装イメージが急速に固まったのでまとめて終了。

全知検索窓では，下スクロールで隠れ上スクロールで現れる固定表示を採用することにした。

昨日，寝る前に Android 版 Chrome を触っていて思いついた（上スクロールでツールバーが現れる）。以前にもこの方式を検討した記憶があるが，その時は流してしまった。昨年，新規描出フォーム固定機能とともに大きく検討を進めたことがあった（開発記録）ので，時期的な噛み合わせだろう。

いったん削除した理由，その後復活させられなかった理由は主に二つあった。

一つは，広告との相性の問題だ。AdSense では広告に固定メニューのようなものが被ることもグレーとされている。実際には悪質でなければそこまで厳しく対応されることはないだろうが，広告頼みのデライトではわずかなリスクでも避けたかった。

もう一つは，画面を広く使いたい場合に邪魔になることがあり，必ずしも便利ではなかったことだ。当然，スマートフォンのような小型端末ではこの問題が顕著になる。

昨年の検討では，広告に近付いたら隠すようにすることと，表示領域の高さが十分ではない場合は固定機能を無効にすることでこれらの問題を回避する方針を固め，復活に向けて一歩前進した。しかし，実装と調整の煩雑さに対して必要性が高まらず，ここまで実作業に至らなかった。

今回採用を決めた方式なら，調整の手間はほとんどかからず，交度も半分くらいで済みそうだ。無くてもそこまで困らない機能ではあるが，これくらい実装コストが下がれば優先順位も上げられる。

日次出場抜控の整理作業（6歩），当努整理（7歩）を済ませ，デラング整備では Mermaid 対応を終えた（14歩）。出振るい済み。

Mermaid 自体は自分で使う予定もなく，他用者からの要望があったわけでもないが，個人知識管理サービス界隈では人気のある付徴なので一定の客寄せにはなるだろう。

今後の応用可能性を考えると，一年近く前に考案した（希哲16年2月15日18歩）交度埋め込み記法をようやく実装出来たことが一番大きな収穫だった。実際試してみると，Mermaid のような交度を埋め込む記法とはかくあるべきだと強く感じる。Mermaid 対応は交度記法をそのまま使った雑な実装が目立つ。言語開発者としての自信を深めることも出来た。

というか，GitHub 開発者よりデライト開発者の方が賢い証拠ではないか。つくづく不思議だったが，コードフェンスに Mermaid の素出を書いて図表を表示することを思いついた人は，コードフェンスに TeX の素出を書いても数式が表示されない理由について考えなかったのだろうか。それを平気で受け入れる人が多かったということは，それが普通の開発者の言語感覚なのか。

（進捗時限記録中略）

知名欄・描写欄の捕活（フォーカス）に関する仕様検討の結果，ともに「マウスオーバーで捕活する」仕様を確定・実装した。出振るい・手定め済み。

なお，知名欄の自動全選択については正式に廃止を決定した。

仕様というほど明確なものではなく，時期によって実装上機能しないこともあったものの，デライト初期実装からのマウスオーバー時の挙動は，知名欄では捕活・全選択，描写欄では捕活，という方針だった。これは，実用上の都合というのも大きく，こうでなければ単純に描出効率が悪かった。

昨年9月までの第二次用合い改良中の交度整理で，知名欄の捕活・全選択は機能しなくなっていた。これは確か，中景輪符の事象（イベント）を改良したことで干渉の懸念があり，再実装を後回しにしたという経緯だった気がする。もっと地味な描写欄の捕活は過去に何度か再実装した記憶があるものの，どの時点で機能しなくなっていたのかは曖昧だが，いずれにせよ，第二次用合い改良後はどちらもマウスオーバーでの捕活すら機能しなくなっていた。

もしかしたら，これはこれで今のデライトでは悪くないのかもしれないと少し様子を見ていたが，輪郭整備のように描出効率が重要な作業になると，クリックでの捕活はやはりまどろっこしく，鈍重に感じる。そこで最近はかつての挙動を復活させる機会を窺っていた。

懸念は，他要素・他機能との干渉や誤操作だったが，これは昨日の検討から急速に氷解した。今のデライトで，マウスオーバーで捕活が移動すること自体は前提のようなところがあるので用者体験に大きな悪影響はないだろうということ，むしろほとんどの要素がマウスオーバーに反応するのに知名欄・描写欄が無反応なことが直感性を損ねているとも言えること，スクロールとの干渉も実際の舞覧（ブラウザ）では生じないこと，誤編集の問題については，そもそも閲覧・編集用合いを切り分けていることが一定の保護機能になっており，更に取り消しボタンで変更有無が分かるようになることで大きく軽減されること，などの理由で，大きな問題はないという結論に達した。

そこでまず，知名欄の全選択も含めてマウスオーバーでの捕活機能を復活させてみた。ところが，知名欄の全選択については数十分で廃止を決定することになった。実装上の問題としては，選択状態がやはり周辺要素と干渉する。干渉しないようにマウスアウトで解除すると，今度は選択状態が意図せず解除されやすくなる。もっと問題なのは，誤入力で上書きしてしまいやすいということだった。全知検索窓では再検索のためにも上書きしやすい全選択状態が好都合だが，知名欄での利点は写し取りが素早く行えることくらいでさほど大きくない。

これは，今のデライトで，慣れ切ったこの挙動からいったん離れなければ気付かなかったことかもしれない。今のデライト市場戦略から考えても，熟練用者向け過ぎて採用出来ない。

次に，知名欄の全選択機能を外し，捕活だけにしてみると，これはむしろ想像以上に好感触だった。地味ながら，編集の軽快感は明らかに向上している。捕活さえしてくれれば Ctrl + A で写し取りも十分効率的に行える。今のデライトとの相性でいえば理想形とすら思えた。ここで正式な仕様として確定することにした。なお，捕活時に発生するスクロールは意図しない場合が多く考えられるため抑止する。

どこまで普遍的な現象か分からないが，常用している Linux の Firefox では，<textarea> の選択状態を残して捕活解除すると，再選択のつもりが（未捕活状態のせいで）意図しない文字列ドラッグが発生しやすいため，これがなくなったのは個人的に嬉しかった。近頃多用している複数輪符の引き入れ欄への写し貼りで障害になっていた。

とにかく，第二次用合い改良後に残っていたもやもやしたものを払拭出来たのは大きかった。

いったん出振るいを終え，他自我内検索用合い改良兼自我ページ整備が一段落した。

開発時間が確保しにくい時期だったことや交度整理に時間をかけたことで12月22日に着手してから日数はかかったが，総合的に満足出来る結果となった。

特に，実装時期の予測すら出来なかった自我ページ整備が出来たことが大きい。これで新生デライト像が完全なものになった。自我ページ整備自体の作業時間は正味2日間程度で，時間対効果も非常に高かった。

今後はまず新生全知検索整備に戻り，輪郭整備兼文書整備と並行させ新生デライトの成立を目指すことになる。

実装について

12月19日の検討通り，他自我内検索時に自我アイコンを並べ，自我ページではこれをプロフィール風に見せることにした（整備後1，整備後2）。

見ただけではまずやり方が分からなかった他自我内検索が整合的かつ直感的に行えるようになり，自我知番による検索結果に過ぎず一見意味の分からない自我ページ（整備前）も一応プロフィールページらしくなった。

自我ページは，デライトにおける自己表現の入り口となる部分であり，初めてデライトに触れた人がまず覗いてみる部分でもあるので，直感的に理解出来るようになったことは大きな進歩と言える。最低限の又情報も設定したので多少の SEO 効果も望める。あとは風船輪郭が出来れば，デライトのプロフィールページとしては無駄なく十分なものになるだろう。