{コマンド プロンプト}{駒手記法}{進捗記録}{場筋}{採用しにくい}{`\>`}{ドライブレター}{`C:\>`}{`:>`}{`PS>`}...=}(37)

{希哲16年1月23日21歩 K#F85E/A-E74C-9337}

進捗時限記録中略

駒手記法コマンド プロンプトPowerShell 対応について検討して終了

以下のような形で実装していくことにした。

:> [コマンド プロンプトの駒手]
C:\> [〃]
PS> [PowerShell の駒手]
PS C:\> [〃]

以前から対応については考えていたが,Windows 系の駒手欄特徴をどう掴むかが難しかった

PowerShellPS> でいいとして,コマンド プロンプトC:\> では明らかに冗長だ。ドライブレター場筋情報必要ないことの方が多いだろう。越化記法との兼ね合い考える\>採用しにくい。となったら,:> しかないだろうということになった。ドライブレター場筋任意付加出来ることにする。

{色見本}{色見本記法}{進捗記録}{文字装飾記法}{簡易的}{直感的に使える}{出揃った}{希哲16年1月23日12歩}{色記法}{希哲16年1月23日の進捗時限}...=}(36)

{希哲16年1月23日16歩 K#F85E/A-E74C-79E5}

進捗時限記録中略

12歩で概ね文字装飾記法出揃ったが,ここまで来たら「色記法」も欲しくなってきたので急遽検討して終了

流石にもう直感的に使える記号残っていないだろうと思ったが,% がまた悪くない原色割合とその組み合わせだ。

例えば,%red%赤い文字%%%#FFFFFF%白い文字%% という表現が出来るかもしれない。%white:red%白い背景に赤い文字%% というように背景色指定出来るようにすれば,簡易的色見本も出来る。装体調整について考えることはく,色見本記法考えていたので丁度良い

{進捗記録}{導入する}{文字装飾記法}{下線記法}{斜体記法}{太字記法}{打ち消し線記法}{希哲16年1月23日16歩}{微妙な要求}{たまにあった}...=}(94)

{希哲16年1月23日12歩 K#F85E/A-E74C-5AE3}

進捗時限記録中略

3歩きっかけ久しぶりに実装予定文字装飾記法について見直し,以下のように基本的方針整理した

<<大きい文字>>
>>小さい文字<<
##太字##
//斜体//
__下線__
~~打ち消し線~~

下線記法については,_下線_有効にすることも考えていたが,適当に書いた時の誤解釈増える懸念もあり見送ることにした。文字装飾記法2個以上記号統一した方が綺麗にまとまる簡潔な記法追加するより削除する方がずっと難しいので,使用頻度考えてもいまあえて導入する動機に乏しい

……ここまで考えて昨年6月23日10歩でも同じ結論を出していたことに気付いたが,再確認出来た。


太字記法については,昨年6月23日9歩では ++太字++検討しているものの,最近 ++行内埋め込み記法利用することを考えているためこれは避けたい。そもそも「強調ではない太字」という微妙な要求のための記法であり,廃案脳裏をよぎった

分かりやすい代替記法がありうるのかと思ったが,意外と ##太字##悪くない。「くっきりした」という意味シャープにもかかっているし,見た目濃さ丁度良い後述文字サイズ記法同様,記号の数濃さ調整出来ても面白い


ついでに<<大きい文字>>>>小さい文字<< という文字サイズ記法思いついた大きさ小ささ記号の数調整出来てもいい。直感性申し分ない

あまり文字を大きくしたい思ったことはないが,小書き括弧記法を使わずに文字を小さくしたいと思うことはたまにあったので良い拾い物だった。


斜体記法打ち消し記法については特に変更無し


上線記法検討していたが,ここまでで HTML の要素相当するものはい,軽標記言語としての表現力十二分なので,いったんここで一区切りとすることにした。

{進捗記録}{AsciiDoc}{特殊な例}{生じていた}{再確定}{ボタン記法}{希哲16年1月23日の進捗時限}{希哲16年1月23日の進捗}{希哲16年1月23日}{行内埋め込み記法}...=}(55)

{希哲16年1月23日4歩 K#F85E/A-E74C-6C79}

キーボード記法についての再検討終了

キーボード記法に関しては,改めて [_X_] 記法中心にしていく方針再確定した。また,[_X_] + [_Y_] を一つの記法として扱うことも明確化した。


[_X_] 記法導入して一件落着かと思ったキーボード記法だが,その後,少し迷い生じていた

この記法ボタンらしく見え過ぎるせいで,ウィジェットボタンにも応用出来る「ボタン記法」のようなものも可能なのではないかというが出てしまっていたAsciiDoc にはボタンメニュー表現出来るマクロがある)。それが可能なら,[_X_]キーボード記法とすべきではないかもしれない,という気がした

ただ,[_X_]キーボード記法一般化した「ボタン記法」にしようかと考えてみたところで,そもそも千差万別外観を持つウィジェットボタン抽象的表現出来る装体存在しないことに気付いて廃案となった。確かに記号としてみるとボタンらしいのだが,ボタンらしい装体を付けようとすると全くイメージと違うものになってしまう。これではあまり意味が無い。あくまでも言語的に扱うか,視覚的に扱いたければ画像素材行内埋め込み記法挿入するのが適切だろう。

そう考えると,キーボードキーに使う装体キー記号としてちゃんと機能するのは特殊な例だ。

=}
{進捗記録}{文字装飾記法}{逆に並べる}{希哲16年1月23日の進捗時限}{希哲16年1月23日の進捗}{希哲16年1月23日}{開始記号}{終了記号}{悪く}{組み合わせ}...=}(18)
{進捗記録}{認識しやすい}{兼ねている}{おまけに}{多々ある}{二段階方式}{下見ボタン}{確認ボタン}{最有力案}{増している}...=}(90)

{希哲16年1月23日1歩 K#F85E/A-E74C-27DA}

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

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


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

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

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

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

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

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

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

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

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

=}