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

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

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

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

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

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

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

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

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

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

のんびり作業しながら開発組計について整理した。最近の脳爆発でまた混沌としてきた頭の中がだいぶ整理出来，脳疲労感も一気に和らいだ。良い休日の過ごし方だ。

まず，第四次宣伝攻勢は，遅くとも黄金週間初日の29日には始める。多少の助走期間も欲しいので，下旬の出来るだけ早い内に始めたい。その前に新生デライトの完成，と行きたいところだが，やや無理がある。無理をして不眠不休でやれば出来ないこともないだろうが，今のところそこまでの必要は感じていない。

無理のないところで，6月までの新生デライトの完成を目指すことにした。ちょうど6月まで様子を見ることにしていたが，新生デライトさえ出来れば収益がどうであれどうとでもなる。これが現状の最適解だろう。

宣伝で認知されてから実際に流入が始まるまでには多少の時間差もある。第四次宣伝攻勢前には，新生デライトの当努のうち，訴求効果や必要性の高いものを優先して詰め込む。

こまごまとした問題は合間合間で片付けるとして，大きな当努では，まず輪郭選り手抜控機能整備を片付けたい。今のところ，最も長く中途半端なまま引きずっている当努で，心理的負担が大きい。先日終えた Aejs 整備の目的でもあった。KNEST 隠し実装も昨年から中断しているが，これは具体的な作業がほとんど出来なかったため，状態としては他の当努と大差ない。

その次は，Aejs 整備の再開前の Cμ 文字列処理改良に戻り，1月29日12歩で決めた通り，続いて描写渡括の実装に入る。さらにその次の優先順位をめぐって頭の中で争っているのが，輪郭小窓の暫定実装と公開設定機能部分実装だ。どちらも用者体験にとって大きな印迫がある。集客する以上，高速化も文書整備もデラング整備も一定の水準以上に進めておく必要がある。

これらを黄金週間前に上手くまとめることが当面の目標になりそうだ。

「まだキエフを落とせないロシア軍」と今は言われているが，落ちたら落ちたで，決して小さくない国土・人口・軍を持ち，国際世論を味方に付け，士気も高い国の首都を“たった”○日で落とせたロシア軍，という現実に直面しそう。

また脳爆発に身体が追い付かない感覚があるが，頭の中では開発上の課題がするする解決している。

出来たばかりの前次記法も，想像よりずっと有用性が高く，既存のデライト記法ともよく調和している。今後の輪郭整備全般に大きく貢献するだろう。考えてみれば，初期のデルンに自動取得機能を付けようとしたくらいで，ずっと必要性は感じていたものだ。手に入れて初めて収穫の大きさに気付いた。

日曜日なので半休にして，のんびり15日分のまとめでも片付けようと思ったが，想像以上に時間がかかった（最後の24歩）。

よくあることだが，描き出してみて初めて膨大な思考量だったことが分かる。

デラング的転回の後，デライト市場戦略におけるデラングの重要性が一気に高まったことで，「デラング」の検索語としての利点に気付いた。

いま Google 検索してみると，外国の地図と「もしかして」が表示されてしまっているが，一応最上位になっている（"デラング" の Google 検索結果）。この調子なら間もなく独占出来そうだ。さほど期待していなかったので棚から牡丹餅みたいなものだが，第四次デライト市場戦略への期待がさらに高まった。

他方，もっと長く多用してきた「デライト」や「デルン」の方は完全に埋もれてしまっている。

「デライト」に関しては，「デライト メモ」のように検索すれば最上位に出てくる。そもそも普通のカタカナ英語なので，埋もれやすいことを想定して「なんでもメモ、デライト」という獲句を考えたのだが，それにしても「デライト」単独での上昇が思ったより遅い。認知度の高い固有名詞が無いからそこまで上位表示は難しくないだろうと思ったが，中小規模の用例が意外に多い。将来的にはともかく，立ち上がりには厳しい検索語だった。

「デルン」の方は，あえて耳慣れないように造語したのだからすぐ独占出来るだろうと思っていたが，10年以上使っていて全く上位表示されなかった。よくよく検索結果を観察してみると，どうも語に部分一致するページが多い。耳慣れな過ぎて，そもそも単独の語として認識されていないようにすら見える。短さも裏目に出たか。

サイト全体への検索流入は良好に推移してきただけに，逆効果になる可能性を考えると下手に作為的な SEO も出来なかった。単純に Google 検索してみると，「デライト」で136万件，「デルン」で20万件弱，「デラング」で2,400件と，見事に桁が違う。結局，競合が想定より多かった上に，雑多なページが膨大にあるせいで評価が分散したのが原因だったのだろう。

デラングが図らずも三度目の正直になったが，ここまで検索に強い商標を作るのが難しいことだとは思わなかった。市場戦略的なことを考えて作り込んだ「デルン」や「デライト」よりも，語感が良く使いやすいというだけで使い始めた「デラング」の方が強いのも皮肉だ。

（21日の振り返り日記）

（進捗時限記録中略）

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

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

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

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

検討過程

3つの検討方針

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

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

記法の趣旨からしても，軽量標記（マークアップ）言語の特性を考えても，1つ目に無理があるのは明らかだ。対応する HTML の <b>，<i>，<u>，<s> は，私が何度解説を読んでもややこしく感じる代物だ。それを多くの人が正しく理解して使うのは不可能だろう。そもそも「文字装飾記法」という分かりやすい説明体系を捨てることになるが，代替案があるわけでもない。

かといって，2つ目ももったいない。要は <span> で装体指定だけにするということだが，例えば，太字にはしたいが <b> にはしたくない場合，打ち消し線は引きたいが <s> にはしたくない場合がどれだけあるのかと考えると，無難を通り越して臆病過ぎる。失う可接性（アクセシビリティ）や応用可能性と釣り合わない。

最終的に採用することになった3つ目も，全く考えなかったわけではないが，柔軟性に欠け，前の2つの悪い所が組み合わされる気もして，有力案にはなっていなかった。

タグ記法による書き分け

この膠着状態を変えたのは，前日に概念としてまとまったばかりのタグ記法だった。

これまで，デラングにおける HTML は，どうしてもデラングで出来ない表現をしたい場合などの“抜け道”とか“救済措置”に近い位置付けで，積極的に使うことを想定していなかった。実際，個人的にはほとんど使っておらず，放置している不具合も多い部分だった。

デラングのタグ記法として間接的に HTML を使うことで，略記法の導入も可能になり，HTML 側の仕様変更に対しても一定の緩衝帯を設けることが出来る。ここに来て初めて，文字装飾記法でも「書き分け」が考えられるようになった。文字装飾記法に対応しうるのが全て1文字要素だったことも幸いした。

昨日の寝る直前に，##太字的な表現## と <{font-weight:bold}>太字</> のように書き分けるよりも，##太字## と <b>太字的な表現</b> のように書き分ける方がマシであることに気付いて，1つ目の実装方針案は完全に潰せた。

これにより一時的に2つ目の実装方針案が再浮上したが，標準的に使う記法として標準的な用途に最適化不足なのはやはり否めなかった。

決着

最終的に，「文字装飾を伴う慣用表現」という用者が自然に理解出来る範囲での意味論的な位置付けを与え，逸脱する用途ならタグ記法で書き分けるのが使用頻度に対して最適だろうという結論に達した。3つ目の実装方針案を洗練させた格好になる。

例えば，##太字## は「太字装体の <b>」に対応する。装体が邪魔なら <b>太字的な表現</b> と書けるし，意味が邪魔なら <{font-weight:bold}>太字</>（略記法は検討段階）のように書けるが，これらの場合が稀少なのは明らかで，記述量に上手く釣り合う。ワープロならともかく，軽量標記言語を手書きしようという人にとって難しい使い分けではないだろう。

そもそも，<b>，<i>，<u>，<s> は，古くからある視覚的要素が HTML5 で慣用的な用途を引き継いで意味論化されたものなので，「文字装飾を伴う慣用表現」と非常に相性が良い。相互変換にも全く問題ない。

何より，直感的に入力すれば構造的に出力されるというデラングの理想に適っている。

文字サイズ記法・色記法は廃案へ

文字装飾記法を「文字装飾を伴う慣用表現」と位置付けたことで，慣用表現を持たない文字サイズ記法・色記法は仲間外れになるが，タグ記法によって出る幕がなくなった感があるので，ここで廃案にすることとした。

第一に，タグ記法で略記法を整備した方が一貫性も応用可能性も高い。特定の値でプロパティを省略出来るようにし，<{white}>白い文字</> のように書ければ，%white%白い文字%% と書くのと記述量も大差ない。

もともとパラメーターを必要とする記法の異質感はあり，文字装飾記法の統一感を損うかという懸念はあったので丁度良かった。

波及的検討

波及的に，いくつかこまごまとした検討も進んだ。

組み合わせは「逆」ではなく「入れ子」へ

これまで，複数の文字装飾記法の組み合わせは #/太字と斜体/# のように，「記号を1つずつ逆さにした終了記号と挟む」といったややこしい説明を考えていたが，##//太字と斜体//## のような「入れ子」を #/太字と斜体/# と短縮出来るという考え方にした方が分かりやすいため改めることにした。

タグ記法の発展

今回の検討で，タグ記法が早くも実践的な役割を持つことになり，デラングにおける存在感が一気に増した。

タグ記法に HTML の仕様変更に対する緩衝的な役割を持たせること，要素名の省略で <span> にすることを考え始めた。

余談ですが，Ｌ字型の見出しスタイルは昔希哲館のサイトで使っていたことがあったのを，おかげで思い出しました。

というより，Ｌ字型自体は CSS で見出し的なものを装飾するのに，昔から（とりあえずこれでみたいな感じで）よく使われているパターンなので，自然に試したのだと思います。B̅ さんのアイデアが面白いのはそれを複数本にするというところだと思うのですが，最初の第1階層がデザインとして野暮ったい上につまらない（昔の CSS 解説サイトみたい）のが個人的には痛いです。この第1階層は実際に使ってみても想像以上にダサい代物であるということは黒歴史として後世に伝えていきたいです。

それが階層の表現であることに気付く前に，とりあえず折り曲げてみた感じに見えてしまうというか……。デザインにおけるダサさというのは，要は「削れるものをとりあえずくっつけている」感じなのです。「いるかそれ？」と思われたら負けで，それが垢抜けない印象になるわけです。その意味では，むしろ「（見本のように）並べてみないと良さが分からないデザイン」になっていると思います。

ちなみに，その案に一貫性があるとすれば下層に行くに従って左線の数が増えていくことになりますが，この方式は階層的に小さい見出しが不必要な目立ち方をする上に気持ち悪いことになるのは目に見えているな，と思って没にしたのが見出し装体素案です。

経験上，見出しはとにかく目立つ要素で，下手に凝ろうとするとデザイン的な事故になる可能性が高いので，「引き算」が重要と感じています。

その帰結が，文字と下線だけで階層を表現する，という現在のスタイルです。初見では目立たない単なる区切り線ですが，二本線が次第に消え入るような一貫した表現で，階層を判別する必要十分な機能を持たせています。おまけに，デライトでも導入予定の Markdown の見出し記法にも一致しています。自分でいうのも何ですが，これ以上の案を出す，というのは結構難しいデザインの課題だと思います。

ただ，デザインというのは感覚でするものでも好き嫌いでするものでもないので，納得出来ないことをどんどん投げつけてくれる B̅ さんとのこういう議論は言語化のために非常に有意義だとも感じています。