{「描写」 K#F85E/A-4686-63EC}

「換配確認機能」についての再検討で終了。なお，この検討から「下見（プレビュー）機能」に改称した。

下見機能は，輪郭選り手左下に下見ボタンを置く形でほぼ確定か。

デラング整備の進展とともに重要性が増している下見機能だが，用合いをどうするかについてはまだ少し迷いがあった。

一応の最有力案は，輪郭選り手左下に「確認ボタン」を置くというものだった。左上は公開設定機能，右上は取り消しボタンに使いたいので，左下に置くのが自然ではある。

完了ボタンと並べるという案も捨て切れなかったが，押し間違いが多発しそうで用合いとしては難がある。

今朝ふと，確認ボタンから描き出し・完了ボタンへの二段階方式が浮上してきた。つまり，必ず換配確認をしてから描き出し・描き直しを行うことになる。

二段階方式の利点には用合いの単純化や初心者にとっての流れの分かりやすさ，おまけに捌き手の負荷軽減も見込めるが，使い慣れた用者にとっては煩雑になり過ぎる懸念があり，採用は見送った。

ある程度複雑なデラング記法を使う場合など換配確認をしたいこともなくはないが，確認するまでもない描き直しも多々ある。また，公開設定機能の導入によって気軽に描き出し・描き直しが出来るようになると，役割が重複してしまう。

一つ，輪郭削除の確認機能を兼ねられるかとも思ったが，そもそも知名・描写を空にして削除というのが確認作業も兼ねているためこれもやはり煩わしい。

やはり，換配確認は選択的な機能にしておくべきだろう。

これまで，完了ボタンに近い位置に置くことも考えていたため，描出の流れの中で分かりやすいように「確認ボタン」「換配確認機能」などと「確認」をプレビューの日本語表現として採用していたが，ある程度独立した機能として認識しやすいように今後は「下見」とすることにした。

公開設定実装方針検討で終了。

公開設定に関しては，まず「自分だけ」（未公開非共有）のような実装しやすく重要性の高いものから，出来るだけ早く部分的に実装することにした。

輪郭選り手はもちろん，他要素の設計にも影響を与える部分なので，早期に見通しを良くしておきたい。

閲覧権限によって描写内の輪符の扱いを変える（鍵マークでも付けるか輪結を無効化するか）ということも考えていたが，これは効率上の問題が大きいため見送り，とりあえずは書き手の配慮に任せることにした。未公開状態の輪符が多いと無駄に輪結を踏ませてしまうという懸念からだったが，その点は輪郭小窓である程度補えるだろう。

主に輪郭選り手抜控機能整備。Aejs 整備も多少進んだ。

まだ荒削りながら，とりあえず描き直しでも描きかけの描写が復元出来るようになった。

先日の違了処理整備と併せて，違了や誤遷移で出与え消失が生じやすいというデライトの課題が一応の解決をみて，信頼性が大きく向上した。

抜控機能によって自動ページ展開機能（無限スクロール機能）の単純化にもなりそうなことに気付いた。

新規描出フォームをどう見せるかが課題だったが，複数窓で同一画面に同期された新規描出フォームが表示されることに慣れてみると，同一ページにあっても不自然ではないと思える。とりあえず，単純に10輪毎に表示するだけの実装でも良さそうだ。

舞覧手定め環境整備の一環として，LambdaTest の正式採用を決定した。

輪郭選り手抜控機能整備続き。

描き直しでも描きかけの描写が復元されるようにしたところで終了。

細かい挙動に調整の余地は大きいが，誤遷移で出与えが消失しないという最も重要なことは実現出来たので，今日はこれでよしとする。

ここからデラング文書整備を最優先にすることにした。

デラング文書の導入

「デラングとは？」が大分良い感じにまとまってきた。

軽量マークアップ言語に関する予備知識の無い入門者にもその意義を伝えつつ，デラングの特徴を表現する難しさがあった。

ここで「軽量マークアップ言語」という翻訳語の限界を感じ「簡易マークアップ言語」を使うことにした。

前日に思いついた時は，独自用語のようになるとかえって理解が難しくなるかもしれないと思ったが，英語版 Wikipedia では〈simple markup language〉が〈lightweight markup language〉の同義語として掲げられていることもあり，こちらの翻訳語として採用することにした。

閲覧専用模動と多重輪括弧

寝る前になって閲覧専用模動についての考えが急速にまとまった。

各輪郭を，閲覧専用に余計な装飾・機能無し（輪郭であることを意識せずに読めるような形）で表示出来るようにする。デライト文書のために考え始めたが，広く有用なものなりそうなので汎用的な設計にしておく。

（「公式模動」や「正装模動」という名前も考えたが，翌日のまとめ時点で，平たく「閲覧専用模動」とした）

いまデラング文書を K#F85E の描出として書いているが，これをどう公式文書として見せるかという課題があった。

kind() の技法で描写を埋め込むこと自体は簡単だが，輪符の扱いが面倒だった。

ここで，デルン最初期の構想が蘇ってきた。もともと，デルンでは通常の輪括弧と二重輪括弧で輪符の目立たせ方を変え，ズームするようにボタンで表示水準を切り替えられるようにする，という機能の構想があった。アイコンには {} や {{}} といった記号を使うことを考えていた。

この考え方が閲覧専用模動にそのまま使えた。この時のために取っておいた二重輪括弧をようやく使える。閲覧専用模動では，通常の輪符は無視し，強調輪符と多重輪括弧のみを輪結にする。

最近，輪符の輪括弧を表示させる記法として二重輪括弧を使おうかと考えていたが，全知検索では二重輪括弧を括弧付きで表示する。閲覧専用模動でも括弧付きで表示したい場合のために三重輪括弧も使えるようにし，これを「多重輪括弧」と呼ぶことにした。

さらに，輪結先も閲覧専用模動にしたい自我を指定出来るようにしたり，特定知番を別 URL に変換出来るような仕組みがあれば，任意の自我で描いた輪郭を違和感なく公式文書にすることが出来る。

全知検索から閲覧専用模動への移行は，各輪郭中景部の丸みのある部分に三角形のアイコンで輪結を置くのが分かりやすそうだ。

これで K#F85E で心配せずデライト文書を書き進められる。

強調輪符と輪結装体（リンクスタイル）についてのまとめ。

これまで輪符の輪結装体 は 1px #999 の破下線にしていたが，通常の線の色は lightgray，引用部区（ブロック）など WhiteSmoke 背景の上では silver と，かなり薄くした。強調記法に単独で囲まれた輪符に関しては，silver の一本下線にし，少し目立つようにした。

これにより，輪結（リンク）の重要性に応じてメリハリが付くようになり，重要性や変調をさりげなく示唆したいような場合は軽い強調，はっきり強調したい場合は重い強調というように，強調記法と組み合わせた「強調輪符」の記法が確立した。

輪符自体を強調するのではなく，参照名を強調したいのであれば内側に強調記法を置くことも出来る（例：軽い強調，重い強調）。

経緯

長い歴史

輪符の表示をどうするかという問題は，デルン最初期からの課題だった。

最初は重要な輪符を少しずつ貼り付けるような使い方しかしていなかったため大きな問題ではなかったが，いずれ文中に輪符が増えてくれば，重要性によって表示し分ける必要が出てくる，というのは当初から想定していた。元々，入力道手（メソッド）の機能や自動補完などで文章のほとんどが意味符号になるような技術として構想していたからだ。

実際，デライト以後，私自身の慣れとデライトの品質向上によって自然と文中に輪符が増えてきた。現在，私の描出ではほとんどの語が輪符であり，輪結になっている。こうなると，閲覧者にとっては，どこが重要な輪結なのか分からない上に，中途半端に目立つ輪結だらけで見にくいという問題が出てくる。

もう一つ，輪符に関する問題があった。輪符の知名を変えて参照したということが分かりにくいという問題だった。輪符の知名を変えたということが読み手にとって重要なことがあるが，これまでそれを表現する良い手段が無かった。

どちらの問題も，少し前までは自動的に解決出来るのではないかと考えていた。例えば，前景輪にある輪符を自動的に強調表示したり，知名と異なる名前で参照された輪符を斜体にするなどということを考えていた。

ただ，これは描出経験を積むにつれ無理があると感じるようになった。

まず，時として膨大になる前景輪に一致する輪符をいちいち見つけるのは現実的ではない。見えている10輪に限定するのも不自然な見え方になるだろう。輪符の参照名をいちいち照合するのも軽い処理ではない。

描写に隠し文字列でも埋め込めば負荷軽減にはなるだろうが，依然として無視出来ないコストではある。何より，出与えの一貫性や保守性に深刻な影響を及ぼすことは目に見えている。

それ以前に，自動装体（スタイリング）を適用すべきではない場合が多々あることも分かってきた。全知検索との兼ね合いも考えると，文中で目立たせたい輪符と引き入れたい輪郭はむしろ一致しないことの方が多い。

知名に関しても，例えば，「知る」という輪郭を「知って」のように語形を変えて参照することも増えてきた。明らかに自動装体にすべきではない，瑣末な場合が多々ある。

最近では，デラング整備の進展もあり，これは手動装体，つまり何らかの記法で対応すべきなのではないか，と考えるようになっていた。

今日の進展

こうした問題の解決に向けて本格的に考え始めたのは，まさに今日，昨日の日記を付けていた時に，「希哲15年6月20日の開発」という輪郭を「開発では」として参照した時だった。この「開発」が，一般的な意味での開発なのか，特定の日の開発を指しているのか，一見して分からない。これは以前からずっと気になっていた問題だが，そろそろ何とかしたいと思った。

重い強調を使ってみたりもしたが，重過ぎる。そこで軽い強調を使ってみることにしたが，軽い強調は欧文向けで，斜体・伊体に依存した装体は避けたかった。ここで，強調輪符の下線を調整することを考え始めた。

強調輪符をいかに目立たせるか，ということを考えているうちに，そもそも輪符の輪結全般が目立ち過ぎていることに気付いた。というより，これまではこの輪結装体が軽い参照も重い参照も表現していたので，気付いてもどうしようもなかった。ここで，通常の輪符と強調輪符でメリハリを付けることを考え始めた。

破線は太くすると環境によって全体的に大きくなり短い語では破線らしく見えなかったりするため，一本下線にすることを考えた。もともと点下線・破下線・一本下線で輪結の強さを表現した装体で，一本下線は前景輪のために取っておいたが，前述の理由で未使用だった。ここで，輪結装体に関する問題全般と繋ってきた。

通常の輪符に関しては，いっそのこと下線類を無くしてもいいかと思ったが，流石に文字色だけでは心許無い。視線の流れを遮ることなく，視線を止めれば容易に輪結と視認出来る按配を理想として，破下線の色を極力薄くすることにし，白背景なら lightgray，引用部区など WhiteSmoke 背景の上では silver が最適と結論付けた。

（Firefox で調整していたためもう一段濃い silver と darkgray の組み合せで決めかけたが，他の環境では破線密度の差でまだ濃過ぎるように見えたため，まとめ中に修正）

強調輪符の一本下線に関しては，薄い色では弱いように思え gray を試したが，明示的に下線を引きたい場合のために下線記法を導入することも考えているため，兼ね合いであえて silver にしておくことにした。

まずは CSS のみでの出振るい。only-child で複数の輪符には効果が跨らないようにしてあるが，テキストノードは含まれうる。本来は一つの輪符のみを強調した時の効果であるべきだが，とりあえずは十分だろう。

総括

開発記録に書いておく。