（進捗時限記録中略）

急遽，新生全知検索整備で終了。

ふと思い立ち，全知検索演算子の実装方針検討と後方一致検索の高速化作業を済ませた。領下では手定め済みだが，特に急ぐことではないので未出振るい。

これまで知名では単純な索引（upper( knm )）1つしか作っていなかったため，完全一致・前方一致では高速だったが後方一致が遅かった。今回，reverse() を使って索引を作る手法で高速化を実現した。手法自体は以前から知っていたが，最近，検索語提案機能について考えることが増え優先順位が急上昇していた。

前方一致と後方一致の論理積で前後一致（両端一致）が出来るし，すでに描写検索で導入している pg_bigm で部分一致も狭義の中間一致も効率的に出来る。これで演算子の整備も捗る。

（進捗時限記録中略）

また新生デライトの要件外ではあるが，ついさっき，急に実装イメージがまとまってしまった輪郭複製機能実装で終了。出振るい・手定め済み。

描写欄が空の状態の新規描出フォームで，自輪郭の輪符を知名欄に貼り付けるかドロップすると輪符から知名・描写が複写される。

複写に成功すると「複写完了」と表示，「複写失敗：自分の輪郭ではありません」と「複写失敗：描写が空ではありません」の違了表示も付け，自我知番の省略にも対応済み。使い勝手は非常に良好。

これまで通り「輪郭複製機能」と呼ぶべきかどうかは再考の余地があるが，眠気で考える余力が無いのでとりあえずは仮称としておく。「輪郭複写機能」の方がしっくり来る気もするが，「輪郭複製のための機能」という意味ではそこまで間違っていない。

輪郭複製機能については，昨年5月18日の開発で「知名・描写を複製して新規描出フォームに移動するボタン」として実装することを考えたが，その後の用合い改良を経て，抵抗感が募っていた。

輪郭を直接複製するような機能はやはり避けたい。手軽にし過ぎると誤操作や濫用の可能性が高まる。適切な手間という点で，新規描出フォームへの複写というアイデアは悪くなかった。ただ，現状の輪郭選り手が理想的にまとまっているので，極力ボタンのような要素を追加したくないと思うようになった。

さっきふと，「知名欄への輪符貼り付け」という案について考えていたら，これが急速にまとまってしまった。過去にも何度か脳裏をよぎった案だが，その時はいまいち気乗りしなかった。

貼り付け方式の最初の懸念は誤入力だった。復元ボタンだけでは心許ないので，知名が空であることを条件にしようとしたが，空の知名で書き始めることは少なくないので中途半端だ。複製したい輪郭を検索してから写し取り，貼り付けという流れを考えると，知名欄をいちいち空にしなければならないのは煩雑過ぎる。

間もなく，描写欄が空という条件なら全く問題ないことに気付いた。誤操作の懸念がなくなったので，ドラッグ＆ドロップにも対応することにした。

もう一つ，自輪郭のみという制限を付けることにした。描写内の自我知番の省略に Aejs で対応するのが難しいという問題もあるが，濫用され著作権上の手溢れが増えることが予想される。他人の描写の扱いは慎重に，という意味でもこれくらいが適切だろう。

こうしてするする実装イメージがまとまり，一通りの機能を付けた実装も難なく完了した。余計な視覚要素を追加せず，それでいて直感的という，理想的な輪郭複製機能があっという間に出来てしまった。

（進捗時限記録中略）

知名デラング調整，関連交度の整理で終了。

新たに，強調記法，文字装飾記法，小書き記法，化学記法に対応した。

いったん全て出振るい・手定め済み。

デラング周りの作業はここで一段落とし，別の作業に入る。デラング関連で次の主要当努は9日の検討通りタグ記法整備の見通し。

知名デラングの拡充については，知名の役割を誤解させかねないという懸念から消極的にすべきかもしれないと考えていたが，20日7歩で極力拡充していく方針を決めた。

実用性の観点でいえば，やはり最短知名原則が有用で，知名に情報を詰め込んだり装飾したりということは推奨出来ない。ただ，間口を広げることを考えなければならない今のデライトには遊びも必要だろう。

デラングを学び始めた人が知名にデラングを使いたくなるのは自然なことであり，そこから学べることもある。知名の役割については，分かりやすい文書を整えることが本筋だ。

手定め中，知名で強調記法を使うと中景輪符の強調部分の文字サイズが大きくなることに気付いた。

<h1> 以下の <strong> に font-size: 120% が設定してあることが原因だった。意図は忘れたが，何かの目的でこんな細工をしたような記憶はうっすらある。

直そうかと思ったが，ちょっと面白い効果でもあるので，いったん置いておき仕様化するか検討することにした。見出しで太字や強調を使う意味は無いだろうと思っていたが，意外と表現方法はあるものだと過去の自分と偶然に気付かされた。

深刻な不具合修正とボタン周りの挙動改良，輪郭削除ボタンでのみ輪郭削除が機能するように仕様を明確化・実装修正し装体調整（7歩）。これまでも輪郭削除ボタンを押下するのが輪郭削除の公式手順だったが，実装上は知名・描写を空にして送信すれば機能した。

不具合修正と輪郭削除ボタンの装体調整がきっかけで，やりたかった輪郭選り手の変更有無を表現する閉じるボタン（×ボタン）の装体イメージもまとまった。

検討中に新規描出フォームの細かい不具合も見つけたのでまとめて調整することにした。

第二次用合い改良でそれ以前にあった「知名欄にマウスオーバーすると自動的に捕活・全選択する」という機能が消えていたが，これを復活させるか検討。

特に意図したことではなく，当初は単に交度整理後の再実装を後回しにしていただけなのだが，これはこれで悪くないかもしれないと様子を見ていた。やはり写し取りに不都合を感じることが多く，全知検索窓との挙動の整合性もあるので復活に傾きかけていたものの，もう少し様子を見ることにした。

マウスカーソルが頻繁に横断する部分なので，捕活がころころ移ると別の問題が色々起きてくるだろう。これをやると描写欄にもマウスオーバーで捕活させたくなるが，そうなると誤編集の可能性も高くなる。その他，スクロールとの干渉など，相互作用を色々考えなくてはならない。

（進捗時限記録中略）

スマホから連続タップで輪郭が削除されてしまったという深刻な不具合報告を受け，修正作業と輪郭削除ボタンの装体調整。

不具合については，描き直しボタンの連打で読み込み中に送信が発生し，知名・描写が空の状態なので輪郭削除と認識してしまう，という可能性が濃厚だったため，以下の修正を行った。

• 描き直しボタン・完了ボタンの多重押下を防止する。
  • タッチ端末では意図せず発生しやすい。
  • 個人機でもうっかりダブルクリックして挙動がおかしくなることが稀にあった。
• 輪郭削除ボタン押下時のみ輪郭削除が機能するようにする。
  • これまでは知名・描写を空で送信すればよかったので，Ctrl + Enter などでも輪郭削除が出来たが，誤操作や不具合によるリスクが高い。
  • 違了表示などは後回しで，とりあえず停止させる処理のみ実装。

b_cfm_udrw のような求頼変数を付けて後縁でも確認させることを検討したが，現時点では過剰と判断し見送った。どの道，前縁が間違った出与えを送れば危険性は大して変わらない。むしろ，上書きされるより輪郭削除が間違って動作してくれた方が取り返しがつく。

前歩のまとめをしながら，知名としての知番が検索出来なくなっていることに気付き修正。出振るい済み。

12月7日の開発から，また輪郭知番を含む検索語でくぐり検索に転送するようになっていたため，逆括点で括った知番のみ例外扱いにした。