輪郭小窓実装など。用合い改良の範囲が全面的なものになってきたため，輪郭小窓実装を中心とした「第二次用合い改良」と位置付けることにした。

デライト高速化における KNEST 隠し実装が一段落した。18日は作業方針検討のみで20日から，休日を除いてちょうど10日間での達成だった。夜に出振るい済み。

全体としては大成功だった。

必要以上に固め過ぎるのも良くないため，隠し化は現時点で最低限必要な範囲に留めたが，期待以上の安定性で期待通りの高速化が得られた。次の施策も出来たので，まだまだ高速化出来る。KNEST 隠しは Dex に匹敵するデライトの武器になるだろう。

交度整理をしっかり進めたこともあり最初の輪数取得改良が想定以上に長引いたものの，ここで KNEST 隠し共通の問題がほとんど解決したため，自我隠し・輪郭隠しは半日ほどで終わった。この交度整理も収穫として大きかった。輪郭操作系の kn の外充て函数を整備したことで関連交度も一気に整理された。

影響範囲と確率的に大きな問題はないだろうと見て，排他制御が甘い部分をあえて残して出振るいを急いだが，出振るい直後に壊衝が多発して少し焦った。すぐに論軸的な問題と気付き修正し，その後はむしろ想定以上に安定して動いている。この判断も結果として正解だった。

輪数取得改良

輪数隠しに関しては，第二次知番改良中に固まった「輪数取得改良」として，輪数取得の仕組みを全体的に改良した。

これまでデルンではいちいち厳密な輪数表示をしていたが，これが大きな低速化要因になっていた。デライト以前まで，count() の遅さに対する認識が甘かった。デライト以後，そもそも出場における件数計算は原理的に遅いもの，と気付いてページ付け（OFFSET 句）に上限を設けるなどの対策はしていた（希哲13年10月14日の開発記録）が，輪数は一筋縄ではいかない部分があり放置してきた。

厳密な同期の必要性や隠し効率から，次のように整理することにした。

• 総輪数は相振り側で隠し化する。
  • 厳密である必要はなく，特に集中しやすい。
• 自我輪数と前後景輪数は出場に保存しておく。
  • 厳密である必要があり，分散しやすい。
  • 前後景輪数では n_fg，n_bg ですでに対応していたため，基本的にこの方式を引き継ぎ，自我輪数用に n_oln を追加する。
    • ただし，従来は変更の可能性がある時にいちいち同期するという非効率なものだったため，これを加減算に置き換える。
• それ以外は表示輪数に10,000輪の上限を設ける。
  • 厳密である必要があるが，一定数以上を知る必要はなく，隠し化は不可能。
  • LIMIT 10001 を付けた副求頼に count() をかけ，10,000輪を越えたら 10,000+ と表示する。

この通りに実装を終え，上手く動いている。

また，この過程で各輪郭操作での輪数更新が必要になったため，ほとんど未実装だった輪郭操作系の外充て函数を整備した。

自我隠し・輪郭隠しから次の施策へ

自我隠しに関しては昨年4月に中途半端な実装をしていたため，これを整理した。輪郭隠しは，現時点で一覧部分には適用出来ないものの一応実装しておいた。

自我隠しが出来たことで自我情報を利用しやすくなったため，自我アイコンに ts_upd を使った隠し破りを付けたかったが，自我情報の取得部分がまだ非効率なので見送った。

輪郭情報も求頼を分割し過ぎているので，これを統合することを考えているうちに，次の施策がまとまった。

輪郭一覧については，まず知番のみで中景輪を取得し，輪郭隠しと照合してから三景の輪郭情報を同時に取得することにした。これで輪郭隠しを効率的に利用出来，求頼を大幅に減らせる。予定していた検索属性もここで盛り込む。

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

出振るい済み。

自動リサイズ機能

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

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

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

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

字数計

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

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

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

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

一昨日から始めていた輪郭整備と目下の課題だったまとめ作業を統合し，「大輪郭整備」として継続することにした。この上旬中に，昨年から引きずっている全てのまとめ作業を片付けることを目指す。

この期間，開発作業は必要性と時間対効果が十分高い部分に限って行うことにした。大輪郭整備に没頭するため，すぐ片付けられるこまごまとした問題は明日まとめて片付けることにした。

昨日，いったんまとめ作業に集中することにしたが，この時点では前次記法実装をした先月24日からのまとめ作業を想定していた。

しかし，一昨日の輪郭整備の手応えが思いのほか良く，昨日も止まらなかった。この勢いで，昨年から引きずっているまとめ作業も片付くのではないか，と考え始めたのが昨晩就寝直前だった。

数週間ならともかく，数ヶ月の範囲になると局所的な「まとめ作業」では埒が明かない。その上，連日新たな収穫がある。というわけで24日以前のまとめ作業は諦めかけていたが，輪郭整備という形で外堀を埋めるようにまとめていくのが意外と近道かもしれないと思えた。

最近出来たパンくず記法・前次記法の効用がやはり大きい。主たる上位階層はパンくず記法で，下位階層は強調輪符を交えつつ箇条書き記法で，前次関係は前次記法で，と基本的な輪郭間関係が書き込みやすくなり，これまで空になっていた無数の輪郭の描写が急速に充実してきている。

一昨日からは暦関連の輪郭整備が本格化し，これがまとめ作業の効率化に繋がりうることに気付いた。これまで，日記にせよ副日記にせよ，年別や月別には整理されていなかった。ずっとやりたいとは思っていたものの，時間対効果に疑問があった。当然，書き込む手間は多少増すが，今のデラングなら閲覧性と操作性の改善がそれよりずっと大きい。終わらないまとめ作業，十分に成熟したデラング，やるなら今が最良の時期だろう。

当然，現状・課題・当努の整理にも，献典整備にもなるが，もう一つの大きな狙いとして SEO がある。パンくず記法実装をした1月14日頃から顕著に検索演心からの評価が上がり，検索流入も増えている。どう転んでも損はしない作業になるだろう。

（6日の振り返り日記）

（進捗時限記録中略）

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

文字装飾記法は，「文字装飾を伴う慣用表現」のための記法と位置付けることにした。太字記法（##），斜体記法（//），下線記法（__），打ち消し線記法（~~，翌日のまとめで「打ち消し記法」から改称）の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> にすることを考え始めた。

（進捗時限記録中略）

コンマ駒手について考えたついでに，描写選り手についての再確認・再検討で終了。

現状の開閉式選り手は，やはり気に入っている部分でもあり維持するしかなさそうだ。閲覧と編集にはそれぞれ最適な用合いがある。

そして，この描写選り手はやはり <textarea> に近い単純なものが良い。WYSIWYG 選り手は多機能化すればするほど挙動の好き嫌いも出てくるし，多様な入力環境に対応出来ない場合も出てくる。高い実装コストの割に失うものも大きい。

そもそも，デラングのような軽標記言語の役割は普文を読み書きしやすくすることであり，そこはデラングに頼っていい。

換配後編集支援・部品単位編集という考え方が出来てから基本的にはこの方針だが，最近，下見機能も含めて輪郭選り手の全体像がはっきりしてきたこともあり，現状単なる <textarea> の描写選り手に加えるべき機能も見えてきた。

中途半端になる懸念から，全く機能を加えないという選択肢もあった。ただ，これは問題の方が大きくなりそうだ。例えば，無番輪符を書いてから下見か完了して輪郭小窓で調整するというのは，現実的に考えると煩雑過ぎる。やはり，その場で輪郭小窓が開いて欲しい。

ただ，昔から考えてきた輪符の折り畳みといった機能は加えない。こういった部分は，せいぜい色付けや輪結化に留めたい。このあたりは部品単位編集との使い分けも考えながら，あくまでも単純性・保守性を損なわない範囲で，デラング編集支援としての機能を加えていくことにした。

部品単位編集も含めて，デラングを設計の中心に据えることで上手くまとまりそうだ。ここでもデラング整備が大きな意味を持ってくる。