{進捗記録}{Markdown}{部区}{希哲16年1月18日の開発}{希哲16年1月18日12歩}{行内埋め込み}{行内埋め込み記法}{書き分けられる}{視覚的な}{導入予定}...=}(161)

{希哲16年1月18日8歩 K#F85E/A-E74C-91F1}

進捗時限記録中略

埋め込み記法渡括記法)の応付子オプションなどについての検討終了

概ね方針が固まってきた

引数風の応付子

これまで埋め込み記法には,埋め込み方細かく指定するような機能がなく,例えば画像埋め込みでも表示サイズ水平方向寄せ方指定出来なかった。この問題当然当初から認識していたが,どうしてもごちゃごちゃしがちな部分なので,直感的美しい記法練るのに時間がかかった差し当たり欲しいのは画像埋め込み表示サイズ寄せ方指定出来る機能だが,他の埋め込み対象でも使える汎用的な枠組み整えておきたい

そこで,[寄せ方指定スペース]+([応付])[埋め込み対象]形式採用することにした。例えば,添付譜類PNG 画像100x100埋め込みたい場合,+(100x100)png書けるようにする。

丸括弧内は,函数引数風にコンマ区切りで,埋め込み対象毎に使える応付子設定する。引数名指定出来るように a=xa:x受け取ってもいいが,柔軟性必要なのであえて必須にはしない。スペースを含む文字列扱いたい場合考えられなくはないのでとりあえずコンマ区切りにしておくが,各引数扱い駒手欄感覚近い

他のとして,+100x100 png+100x100,png のように全てを引数的に扱うことも考えたが,あくまでも埋め込み対象とする応付役割まとまり一番分かりやすいという点で丸括弧採用する。また,埋め込み対象URL など長い文字列になることも多いため,応付+直後置く。あるいは,末尾に置く書き分けられるようにする。

水平方向寄せ方

水平方向寄せ方は,表組み記法採用予定スペースを使う方法応用することにした。以下のように,+ 前のスペース無しは無指定4つ未満は左寄せ4つ以上で中央寄せ6つ以上で右寄せとする予定

+png            <!-- 無指定 -->
  +png          <!-- 左寄せ -->
    +png        <!-- 中央寄せ -->
      +png      <!-- 右寄せ -->

直感性でいえば矢印のような記号導入することも考えられる。となるとまず <>使うことになるが,すでに多用しているため無闇役割広げる記号意味稀薄化しかねない。そうでなければ leftcenterright のようなキーワード導入するくらいしかないだろう。いずれにせよ,見た目的にもあまり美しくない

当初,以下のようにスペースの数表組み記法合わせようとした2つ中央寄せ3つ右寄せが,いくつか問題がある。

+png         <!-- 無指定 -->
 +png        <!-- 左寄せ -->
  +png       <!-- 中央寄せ -->
   +png      <!-- 右寄せ -->

まず,表組みにおけるセル内での編集に比べそこまで編集効率問題にならないためここまで短くする必要もなく,比較的長くなる後続文字列に対して目立ちにく過ぎる単純にスペース2つ中央寄せ3つ右寄せ表現には見えない

さらに致命的な問題は,いくつかの他記法との整合性だ。導入予定字下げ記法では,行頭全角スペース使う。あまり好き記法ではないが,Markdown4つの半角スペースを使う交度記法互換性のため導入する可能性がある。これらの記法混ぜ書いた場合,視覚的な整合性が取れない。

そこで,行頭に使う寄せ方指定スペース表組み記法とすることにした。交度記法にも使われる4つの半角スペース右寄せ一致するよりは中央寄せに一致した方が違和感がずっと小さい

行内埋め込み記法

おまけに,行内埋め込み記法についても少し考えた

これまで埋め込み記法部区として扱うことを主に考えてきたが,やはり行内埋め込み必要だろう。まだ草案段階だが,例えば以下のようにして画像回り込む段落が作れると便利だ。

++png++ 左上の画像に回り込む段落。
=}
{HTML}{HTML5}{進捗記録}{AsciiDoc}{主述記法}{決め手に欠ける}{優先的に}{普及状況}{寄せておく}{重視すべき}...=}(75)

{希哲16年1月15日6歩 K#F85E/A-E74C-98C8}

進捗時限記録中略

<dl>対応する語釈記法仮称についての検討終了

まずは,AsciiDoc複数行ラベル記法取り入れることにした。


以前から 氏が使っていたことで AsciiDoc 風記法導入考えるようになったが,末尾::名称空間知符として多用していたため,語句:: 定義単一行ラベル記法導入するとおかしくなる輪郭がいくらかあるという問題があった。

ただ,最近この手の文字列交度記法利用統一すべきという考えまとまっているため,移行作業問題はあるものの仕様として導入することに問題はなくなった。そこで,すぐに取り入れても問題なさそう複数行ラベル記法から取り入れ,どう拡張するかは追い追い考えていくことにした。

記法名仮に語釈記法」とした。HTML5<dl>〈definition list〉から〈description list〉意味合い変わっているが,語句に対する説明という大まか意味には適っている

AsciiDocラベル記法はもっと汎用的使えるものらしいが,デライト重視すべき HTML では意味付け重要なので,とりあえず <dl>用途寄せておく


他に,Markdown Extra などで採用されている行頭 :記法検討した。記法として悪くはないが,普及状況いまいちで,優先的に採用するには決め手に欠ける

=}
{進捗記録}{越える}{分かる}{知番}{希哲15年12月24日の開発}{導入しなかった}{完全に隠す}{繋がりうる}{知番の強み}{長くなっていく}...=}(116)

{希哲15年12月24日6歩 K#F85E/A-E74C-9D02}

自我知番の省略についての検討終了

昨日の開発から本格的に検討始めた自我知番の省略だが,描写内では輪郭自我知番全知検索などでは録入り中自我知番指す略記法として導入することを決めた

仕様として導入することに大きな問題はないが,難しいのは用合いにどう調和させるかで,これは今後の課題とする。

利点言うまでもなく文字列としての短縮性だが,変則性を一つ加えることで扱い難しくなる懸念もあった。省略有無混乱の元になる可能性もあるため,極力混同させないようにしつつ,ある程度は混同されることを想定した用合い提供する必要がある。この難しさは,これまで導入しなかった正しさでもある。

現状のように自我知番4桁収まっている間は,まだ略記法利点欠点拮抗するだろうが,そのうち8桁になれば流石に邪魔になってくるだろう。将来的に知番の長さ補う方法必要になってくるということは考えていたが,この課題解決策にもなることに気付いたことが決め手だった。

第零番節を除き輪郭知番8桁越えることは機械的な描出でもしない限り)考えにくいが,自我知番4桁なのはむしろ例外的な時期で,いずれ8桁標準になるし,遠い将来には12桁になることも考えておく必要がある。つまり,知番全体20桁まで長くなる現実的な可能性がある。

ここで自我知番の省略が出来れば,少なくとも自輪郭に関しては4桁から8桁輪郭知番だけ考えればいいので,十分な短縮性と言える。他輪郭なら20桁でも扱えなくはない

もっとも,自我知番12桁になるのは40億用者越えてからのことで,輪郭知番4桁もそう簡単には埋まらないので,現実には12桁から16桁知番模量層になるだろう。司組用者成熟度合わせて長くなっていくのが知番の強みだ。


考えている内に,自我知番の省略には無用な自我知番露出避けられる利点もあることに気付いた

テプラ機器知番ったりしているが,人目に触れる場所ではこれも個人情報流出繋がりうる自分だけ分かればいいなら自我知番表記しておく必要はないし,未公開にして完全に隠すことも出来る。

=}
{個人的な感覚}{ローカルアプリ}{あれ}{希哲15年9月5日}{希哲15年9月5日のツイスト}{ツイスト}{外部}{送信}{保存}{気持ち悪い}...=}(13)
{文字列}

{}