一時期，スネオのテーマは作業用 BGM に最適という仮説を立てて一日中聴いていたことがあるが，むしろノイローゼになりそうで止めたのを思い出した。

11時頃から葛西臨海公園，若洲海浜公園，夢の島公園，辰巳の森海浜公園などを巡って17時過ぎ帰った。道に迷うことが多かったせいもあり，昨日の最長記録を大幅に更新し，約48.1km走った。

休日なので少し遠い辰巳の森海浜公園を目指して出発したが，葛西臨海公園を通り，荒川河口橋を越えたあたりで勘違いして左に曲がってしまい，若洲海浜公園に着いた。ここはここで海が綺麗に見える良い公園だった。植物を見るなら葛西臨海公園で十分だったので結果的には良かった。

海を見ながら戻り，15時頃，少し懐かしい辰巳の森海浜公園で休憩した。デライト正式離立前に何度か訪れ計画を練った思い出があり（希哲13年10月7日の散歩記録），なんだか感慨深かった。近便で適当に買ったもので食事を取り再開，葛西臨海公園でぶらぶらしてから帰った。

他の大きな公園を走ってみたことで，葛西臨海公園のサイクリングコースとしての優秀さを再確認した。小さ過ぎず大き過ぎない敷地に見所が凝縮されていて，自転車の移動速度に対する景色の多彩さが絶妙だ。ただ漠然と広いだけの公園で感じる退屈さが無い。希哲荘からの距離も運動には最適で，恐らく最高の場所だろう。徒歩で行くことが多かったので，いままでこの真価に気付かなかった。

（進捗時限記録中略）

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

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

（進捗時限記録中略）

デライト装体調整で終了。

昨日の調整後，描写内見出しで5階層分の装体を用意すると中景輪符が <h2> から始まる場合に第5階層以下の見出し装体が変わってしまうことに気付き再調整（再修正後の画面撮り）。

最終的に，見出し装体は4階層分あれば十分かつ最適と結論付けた。実際には第3階層を使うことも稀だ。

見出し記法の階層の深さに制限は無いが，装体の表現の幅は有限なので，滅多に使わない下位見出しまで考慮すると使用頻度の高い上位見出しの表現の幅が狭まってしまう。

4階層なら丁度4種類の下線でまとまる。第5階層がほとんど単なる太字になっていたので中途半端だった。文字サイズも，分かりやすく 1.3em，1.2em，1.1em，1em と0.1em刻みに出来，しっかりメリハリがついた。

0.05em刻みは Chrome では意図通りに表示されたが，何故か Firefox と Safari の通常倍率表示では 1.1em と 1.15em の違いだけが全く分からないという問題もあった。

<h6> 相当以下の見出し記法は全て <h6> になる仕様は据え置くつもりだったが，これは階層関係の観点から再考する必要があるかもしれない。<p.heading> にしている pandoc のようにすべきか。結局横並びになるなら同じな気もする。

ついに自転車を買った。前々からぼんやり欲しいとは思っていたが，なかなか模体（モデル）が決まらず，大して必要にも迫られず，踏ん切りがつかなかった。

金風以後，市内を中心に買い出しや事務的な用事で歩き回ることも増え，自転車くらいは必要かと強く感じるようになっていた。散歩も徒歩で行ける所はほとんど行き尽くしてしまい，少し飽きつつある。買い出しに関しては，ネットスーパーを利用することも考えたものの，店舗には店舗の面白さや便利さがあり，篭りがちな仕事の合間で良い運動や気分転換になっているので，自転車さえあれば不満はない。

実家にいくつかあった自転車は，盗まれたのか姉が持って行ったのか，いつの間にか無くなっている。最近惹かれていたのはダホン K3 だが，今のところそこまでの可搬性は必要ない。となると走行性能の点で費用対効果が低過ぎる。

もうこの際，実用性と最低限の見た目があればつなぎとしてシティサイクルでもいいかと思い立ち，昼前から散歩がてら自転車屋を巡ってみることにした。最初は近所でよく前を通る小さな自転車屋に入ってみたが，品揃えが少な過ぎたため，少し離れた大型専門店まで足を延ばした。

ここは流石に品揃えが豊富で，いくつか惹かれる模体が見つかった。一番気に入ったのは一通りの装備が付いた20インチ折り畳み自転車だった。趣味用自転車特有の面倒臭さがなく，適度にお洒落感はある。

この系統で黒だと2種類，かなり似た形状のものがあり，一方はフォルクスワーゲンの2021年型 VW-206G で本体価格は3万円台半ば，もう一方は1万円ほど安い独自ブランドの模体だった。そもそもつなぎなので最初は安い方でいいかと思ったが，よく見ると細部の美しさで価格なりの差があり，結構迷った。結局，ここで妥協するなら1万円くらいのシティサイクルと大差ないことに気付いて VW-206G を買った。防犯登録，保証・保守サービス，整備・防犯用品を一通り付けて4万3千円ちょっとで，すぐに乗って帰れた。

最初は1年くらいつなぎで持ってくれればいいかと思っていたものの，買ってみると，意外にも自転車欲があっさり満たされてしまった。元々合理的な移動手段として欲しかっただけで趣味として追求したいわけではなかったし，この模体自体の費用対効果が期待以上に高かった。

走行性能は，ぶらぶら走る程度なら以前所有していたダホンの Speed P8 と変わらない印象で，10万円ちょっとまでの20インチ自転車ではどれと比べても大差ないだろう。都内で見かける自転車の大半より見栄えも良い。

外観に関しては，そもそもこの形状が一番好みだったことに買ってから気付いた。最低限の装備しか付けていなかった Speed P8 と似ているとは初見では感じなかったが，後で写真を見比べると骨格が驚くほど似ていた。愛嬌とかっこよさを兼ね備えるこの感じの20インチ折り畳み自転車が元々ツボだったのかもしれない。新しい2022年型ではフレーム形状が変わってしまっているので買わなかったかもしれない。そう思うとしばらくはこれでいいやという気もするし，後継車のハードルは高そうだ。

見た目優先で折り畳み機能の使い道はあまり考えていなかったが，帰ってみると玄関に置いておくのが最適という結論になり，結果的にこの点でも大正解だった。

およそ10年ぶりの自転車には感慨深いものがあり，夜まであちこち走った。自転車によく乗っていた時期は長くないものの，平日日中でも毎日のように Speed P8 で都心を走り回っていたので，想い出は濃い。天気は悪かったが，涼しくて好都合だった。

考えてみれば，デルンの実用化と引き換えに自転車も自転車でぶらぶら走るゆとりも失ったようなもので，デライトと自転車の組み合わせは新しい体験をもたらしてくれそうだ。最近，睡眠の質が課題なので運動の機会が増えたのも嬉しい。座ってぼんやり考え事をしているよりはサイクリングでもしていた方がいい。

（22日の振り返り日記）

（進捗時限記録中略）

適当にしていた家庭用路定機（Speed Wi-Fi HOME 5G L11）の設置場所について検討。

昨日，移動させながら速度計測してみたら設置場所で思ったより大きく速度が変わることが分かった。

家中の置けそうな場所を試し，最適な設置場所を見つけた。

現状，速度は妥協出来ないこともないが不安定なのが気にかかる。

以前の光回線では，速度を気にするような使い方もせず，実際気にならなかったので速度計測自体まともにやったことが無かった。たまに試して，「こんなものか」と思った記憶だけが残っているので，可もなく不可もなくだったのだろう。

比較のため撤去前に計測しておこうと思っていたが，いざ家庭用路定機が届くと早く試したくなり，設定切り替えした時点で戻すのも面倒になってしまった。

とりあえず，体感的に遜色ない通信品質になれば問題ない。

出振るい作業についての検討で終了。

最近，断帯を伴う出振るいのタイミングに迷うことが多く，結果的にまとめて行うことも多くなっていた。今後，急がない出振るいについては意識的にまとめて行うことにした。

保守作業中ページへの切り替え機能再整備，違了処理整備，輪郭選り手抜控機能整備を経て出振るい作業もずいぶんやりやすくなったが，機会損失に繋がる断帯は最小化したい。

時間帯も，深夜にまとめようかと思ったが，生活律動との兼ね合いがあるため5時台の「早朝出振るい」を心がけることにした。朝のデライト宣伝は6時台が最適と考えてきたため，流れとして丁度良いだろう。

これに伴い，明日から5時前起床を目指すことにした。最近，夜更かしが目立つようになってきたためこれも丁度良い。

近象的であることが良いというよりも，現象の遠近を適切に利用した方が良いとは言えると思います。

進化生物学的に考えれば，動物の脳は，状況に合わせて生存に最適な行動を取るための情報処理を担っているはずです。要は，情報に優先順位を付けて，重要度の高い情報をすぐに引き出せるように出来ています。重要な情報は近くに，瑣末な情報は遠くに置いているとも言えます。この情報の遠近法を形にしたのがデライトの輪郭法です。

この輪郭法は希哲社の「知機」開発プロジェクトの核心ですが，一部です。

例えば，今の一般的なコンピューターの UI では，何かの目的に対し，ユーザーがアプリを選んで対応します。これは十分に近象的ではなく，雑音が多すぎます。「○○がしたい」という時に，「○○を実現してくれる××を使う」のではなく，「○○を使う」と考えられるのが近象的な UI です。

具体的には，統一感の無い絵柄のアイコンや固有名詞ではなく，ピクトグラムのように体系化されたアイコンで，目的を直接的に表現します。コモディティ化したアプリの仕様の大枠はプラットフォームが決め，サードパーティーはその実装を競作するか，実験的なアプリの提供を行い収益を得ます。

こうした試みは無かったわけではなく，Apple も方向性としてはそれに近いことをやろうとしていますが，突き詰めればこういう形になっていくと予想しています。

CLI でも似たようなことが言えます。例えば，「ファイルを全文検索したい」という時に find と何々を組み合わせて……と考えるのは近象的ではありません。grep -r も grep が固有名詞なので近象的ではありません。理想を言えば find 'foo' と書けるべきでしょう。

「知機 Unix 相互運用標準」として希哲館が策定している Synx では，同じことが交度英語で fnd 'foo' と書けます。一般の Unix コマンドと区別するため kn fnd 'foo' とも書けます。

要するに，ユーザーが頭に思い描いたことと，UI の言語体系との間に距離が無いことが，工学における近象性です。この点で現在の多くの UI には課題があると感じています。

今の UI は迂遠なことが多いので主に近象性が課題になりますが，もちろん，より複雑・詳細な表現に対応する遠象性も適切に扱える必要があります。

UI が理想的な近象性を実現した時，物理的に接続しなくても，十分に脳とシームレスに繋がるコンピューターが実現出来ることになります。これを「知機」と呼んでいます。デライトも含めて，それこそ私が目指していることです。

（進捗時限記録中略）

開発環境整備。

作りかけで使っていなかった kn scr を仮想画面単位での窓構成保存・復元に使えるようにしていったん終了。

画面番号や適当な名前を付けて作業に最適な窓構成を駒手一発で展開出来るようになった。各 xterm 用の screenrc を用意し，シェルの状態も細かく制御出来るようになった。

これまでは主力機を起動しっぱなしにしておくことが多く，窓構成も模索していたためいちいち手作業で調整していた。

最近，デライト開発に最適な窓構成が掴めてきたことと，外出が多い上に今年の夏に少し危険性を感じること，そして昨日までに新生デライトの要件がまとまり作業効率を可能な限り上げておきたかったことで機が熟した。

これで臨時の調整，再起動・部分更新などがずっとしやすくなり，作業が捗るだろう。

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

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

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

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

経緯

長い歴史

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

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

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

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

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

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

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

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

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

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

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

今日の進展

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

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

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

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

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

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

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

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

総括

開発記録に書いておく。