もともとは燭台に近いものを指した。

{希哲17年1月25日10歩 K#F85E/E74C-7A41}
吹き描き外背景のダブルクリック/ダブルタップで新規描出フォームに移動出来るようにして終了。出振るい・手定め済み。
デライト最初期,新規描出フォーム固定機能で試していた(希哲13年8月1日4歩)用合いだったが,自分でも驚くほど忘れていた。固定機能の削除以後,何度か再活用を検討した記憶はあるが,今ほど全体的な用合いの方向性が定まっていなかったからか放置していた。新規描出フォームへの握接について先日あれだけ検討していたのに全く思い出さなかった。ついさっきふと思い出した。灯台下暗しというやつか。
初見で分かりやすい用合いも必要なので全知検索窓固定機能の輪結も予定通り実装するが,スマートフォン右手持ちではタップしにくい位置だとは思っていた。個人機でもマウスカーソルの移動距離は短くない。しかし,これならよくある固定表示ボタンよりよほど賢い。上手い補完手段が出来た。
現状の幅狭領当てでは吹き描き外背景が小さ過ぎて誤タップしやすいが,これは縦方向の吹き描き間マージンを調整していくことにした。

{希哲16年3月12日14歩 K#F85E/E74C-2A34}
今後の Dex 設計方針についての検討で終了。これから越化参照が大活躍しそうだ。
まず,課題だった脚注記法の実装方針について検討している内に,越化参照が部区間通信に活用出来ることに気付いた。
部区毎に越化条件の変化などがあることから,各記法の解釈は部区個体に任せたい。しかし,脚注記法のように最上位部区との出与え共有が必要な記法もある。
このような場合,単純に考えれば指示体を通して部区個体間で変数を共有するということになるが,この種の記法が増えるたびに目的別の指示体を増やすのは設計として美しくない。汎用的な変数一つに集約するのも,効率性や厳密性の観点から難がある。
ここでふと,越化参照が使えることに気付いた。下位の部区個体で中途解釈した記法には目印となる越化参照を付け,上位の部区個体で変換処理を完了させる。
これに似た部区間通信の手法は Dex 初期実装から現 &_skp;
で使い続けているが,どちらかというと「邪道」だと感じていたため,意図的に応用範囲を広げなかった。紆余曲折を経て,これが一番単純性・効率性・保守性のバランスが良いということが分かった。
これで脚注記法や目次記法の実装は容易になった。他にも,輪郭情報の参照が必要な記法など,部区間通信が必要な場面全般で越化参照が活用出来るだろう。

{希哲16年1月19日1歩 K#F85E/E74C-5396}
直書き URL(<a.URI>
)を font-size: 0.9em
の等幅フォントにした(URL 装体調整前後)。字間無しは昨年6月30日の開発からだが維持する。
直書き URL のある描写が読みにくい問題はずっと以前から感じていて,何度か調整しているが,一昨日の開発中にふと,「文字サイズを小さくしていない」ことに気付いた。
昨年6月30日の開発で字間無しにしているが,等幅フォントにして変に目立ち過ぎるという理由で戻したりもしている。この時になぜ文字サイズを小さくするという発想がなかったのか不思議だ。他にも問題が山積していて思考時間が割けず,灯台の下まで目が行かなかったか。
今回は <kbd>
や <code>
の装体について考えていたところだったので,その関連で気付けたのだろう。
文字サイズはやはり0.9emが丁度良い。0.8emにすると長い URL はともかく短い URL を提示する時に今度は目立たな過ぎる。
これにより,十分凝縮されメリハリが付いたので,予てから検討していた長い URL の省略については保留とすることにした。
長い URL の省略は,簡単なようでいざ導入しようとすると意外と難しい問題がある。
まず,デライト上の文書の傾向からいっても,「ちょっと長い」程度の URL は省略したくない。URL の全体が情報として有用な場合がしばしばある。このあたりはマイクロブログなどとは事情が異なる。
では,どこで省略すべきかという問題になるが,長い URL を許容すればするほど比較的短い URL の読みにくさが解消されないというジレンマがあった。これは装体の調整で解決した。
そもそも輪結記法([ ... ]
)もあるので,現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx
のような省略記法を導入してもいい。
ただ,パーセント符号化の復号はしたい。これは昨年3月22日2歩で決めていたことだが,少し面倒臭い部分がありいまだに実現していない。

{希哲15年6月21日の開発 K#F85E/E74C-23E5}

{希哲15年1月19日の日記 K#F85E/E74C-F70C}
昨日の日記を付けながら,デライト累新は希哲館累新でもあり,「千年の集約」でいうところの累新に,希哲館黄金期は近代化の過程に相当することに気付いた。
最近,こんなことをぼんやり考えながら時が過ぎてしまうことが多い。脳がよほど情報を整理しようとしているのか,少し思考に引っかかりを感じて手を止めると,そのまま何時間も経っていたりする。そのせいで開発も少し停滞気味だ。
経験上,こういう時は「待つ」以外にこれといった対処法が無いことは分かっているが,流石にそろそろ手を動かしたい。
そう思いながら,デライト公式で希哲館訳語についてのツイストを書いていた。相変わらず,独自性という言葉も陳腐に感じるほどの異形ぶりに,自分は日本の中心部にありながらどんな環境で育ってきたのだろうと改めて感じていた。
あるツイストを書き終えた瞬間、なぜか,幼少期にかくれんぼで大人達を困らせた記憶が蘇えってきた。希哲館事業というのは,自分にとってずっとそんな「わくわく」する悪戯だったのかもしれない。一夜革命なんて,やたら壮大なだけでまさにかくれんぼではないか。久しぶりに「三つ子の魂百まで」という言葉を思い出した。
急に童心にかえったような気分になり,すっと肩の力が抜けてなんだか笑えてきた。
気付いてみればこんな単純なことに今まで気付かなかったのか,気付いたことを忘れているのか,灯台下暗しということもあるから分からないが,変に嬉しい発見だった。
これだから思索はやめられないのだろう。

{希哲14年7月16日の開発 K#F85E/5B28-1CB3}
今日は前後景輪の一覧実装を始める予定だったが,深刻な不具合などに気を取られ準備程度のことしか出来なかった。
しかし,交度を整理しながら描写選り手周りの改良をよく進めることが出来た。特に,描き直しの挙動はこれまで自分で気に入らないところだったので,洗練されたのが嬉しかった。
以前から怪しかった AdSense と Aejs の干渉問題も根本的な解決策を施すことが出来た。
昨日の開発記録をまとめていて,公開連絡先を使った新しい暗証語忘れ対策を思いつき,この方向でまとめていくことにした。
もう一つ大きな作業方針上の進展として,自我登録時の知番予約改良を一括挿入(バルクインサート)から試すことにした。初歩的なことだが,余裕がなかったのか Cμ と外充て函数を過信していたのだろう。これも灯台下暗しだった。ずっと非同期化の方向で検討していたが,そもそも非同期化しないと困るような処理が自我登録のたびに走っていたら捌き手がもたない,かといって予約範囲の分割も煩雑化を招く,といった懸念があったため,これで済めば万々歳だ。
その他,Twitter Publish と + 記法を使ってツイート埋め込みをする方法について検討など。

{希哲14年7月14日の開発 K#F85E/5B28-66DF}
デライトの諸場用合いで最大の課題だった引き入れの操作性だが,ふと,旧全知検索で実装していた引き入れボタンを思い出した。
引き放ち(ドラッグ&ドロップ)式を重視したデライトの新全知検索に移行する過程で消えたが,スマートフォンなどの諸場用合いで快適に引き入れするにはこれしか無さそうだ。ちょうど前後景輪一覧を整備しようとしているところなので,引き入れボタンを改良して復活させ,諸場用合いではこれを推奨する方針をまとめた。
当初は引き放ち式にとらわれ過ぎていて灯台下暗しになっていた。その後,写し貼り式に焦点を移すが,試してみるとこれも諸場では煩わしいことに気付き,しばらく出口が見えない状態が続いていた。結局原点回帰になった。
