{希哲16年5月28日の開発}{希哲16年5月28日の進捗}{他用者}{直しておいた}{外れやすい}{私の場合}{戻りたければ}{移動しながら}{吊るし輪郭×輪結改良}{希哲16年5月28日の進捗時限}...=}(64)

{希哲16年5月28日4歩 K#F85E/E74C-B3E9}

=}
{希哲16年5月27日の開発}{希哲16年5月27日の進捗}{写し跡改良}{リフロー}{HTMLElement.offsetWidth}{初期化されない}{再追加}{正規の手段}{初期化する}{思いきや}...=}(74)

{希哲16年5月27日15歩 K#F85E/E74C-5453}

=}
{用者}{HTML}{HTML5}{デラング}{進捗記録}{高い}{あれ}{役割を持たせる}{役割を持つ}{緩衝的}...=}(248)

{希哲16年2月15日10歩 K#F85E/E74C-2CA8}

進捗時限記録中略

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

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

{進捗記録}{廃止}{希哲15年12月17日の開発}{kn+/}{持たせた}{将来的に}{バイナリ実装}{スクリプト実装}{無拡張子}{必要に応じて}...=}(63)

{希哲15年12月17日2歩 K#F85E/E74C-7E64}

知機駒手実装整理終了

+ 接尾子使った台録構造について見直した結果これまで必ず置いていた実行譜類への疎輪結のみ「必要に応じて」とすることで概ね現状維持となった。

アンダースコア略記法の廃止により,今後kn+/foo+/bar.sh のような台録構造副駒手管理することになる。いっそのことこの + 接尾子廃止していいかと思ったが,kn+/foo という無拡張子疎輪結使うことでスクリプト実装.shバイナリ実装.x切り替え容易になるという狙いがあり,これはこれで捨て難い設定譜類より直接的分かりやすいし,最上位knkn+/ になるのが自然なのでそれに整合的でもある。

将来的に膨大な副駒手追加することを考えて持たせた柔軟性だが,これまでの実装では無拡張子疎輪結を通して副駒手探索していたため,常に副駒手疎輪結しておく必要があり,スクリプト実装しかない現状ではただ煩雑なだけだった。これを省けるようにすれば柔軟性維持しながらかなり見通しが良くなる

=}
{新しい言語}{希哲15年8月17日のツイスト}{希哲15年8月17日}{ツイスト}{解決}{導入}{Rust}{容易}{犠牲}{安全性}...=}(14)
{進捗記録}{希哲15年8月13日の開発}{見つけた}{求めていた}{知っていた}{交度量}{初回使用時構築}{xt C}{希哲15年8月13日の進捗時限}{希哲15年8月13日の進捗}...=}(39)

{希哲15年8月13日13歩 K#F85E/E74C-2061}

類型化正規表現に関して,xt C だけではまだ不安が残るため,当面は安全性重視初回使用時構築利用することにして終了依存関係単純なうちはまだいいが,将来的複雑性予見出来ない。交度量にもさほどはなく,書き換え容易だろう。

この手法自体は知っていたが,いまいち説明納得出来ず,この場合に適用していいものか迷いがあった。『ストラウストラップのプログラミング入門』求めていた単純説明見つけたので採用することにした。

事実上定数であれば,函数であっても the_ 接頭子を使っていいことにした。

=}
{容易}

{}