{rgx_T}{s_T の補助函数}{進捗記録}{幸いした}{書き換え作業}{置換作業}{必要な時期}{置換した}{冗長版}{置換する}...=}(69)

{希哲16年1月28日16歩 K#F85E/E74C-C804}

進捗時限記録中略

Cμ 文字列処理改良rgx_T の置換道手の引数順序変更

作業方針再検討終了

あとは rgx_T::rpl()引数順序変更rgx_T の置換道手の引数順序変更完了だが,これまでの道手呼び出し箇所Dexごく一部限られていたのに対し,.rpl()Cμ 初期からあちこち使っている置換道手なので,少し複雑な作業になる。

まず,いったん .rpl()適当な名前変えて無効化し,呼び出し箇所引数順序変更済みの .rpl_glb() あるいは客体表現置換するか,正規表現客体表現使うまでもない処理なら s_T の補助函数置換する現時点.rpl_glb().rpl()冗長版に過ぎないため,置換したままにしておいて問題ない交度整理をしていけば自然に戻るはずなので,あえて再置換はしないことにした。

置換作業に入る前に,作業必要s_T の補助函数整備必要だが,既存の「類型化正規表現rgx_x_T置換道手旧式引数順序にならっているため,まず最初に客体表現ojx_x_Tへの書き換え作業済ませることにした。rgx_T直接使った交度から類型化正規表現への書き換え作業想定より遅滞していたことが幸いして,現時点類型化正規表現多くない

いずれにせよ正規表現総点検客体表現への書き換え必要な時期であり,保守性効率性大きな向上見込める良い機会だ。

=}
{用者}{進捗記録}{認識しやすい}{兼ねている}{おまけに}{多々ある}{二段階方式}{下見ボタン}{確認ボタン}{最有力案}...=}(90)

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

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

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


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

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

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

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

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

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

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

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

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

=}(1){あれ}
{デラング}{進捗記録}{廃止}{組み合わせた}{キーボード記法}{見送った}{書き間違い}{下境界線}{上境界線}{邪魔臭い}...=}(111)

{希哲16年1月17日17歩 K#F85E/E74C-835A}

キーボード記法改良終了

従来二重角括弧を使った [[X]] 記法に加え,アンダースコア組み合わせた [_X_] 記法使えるようにした

旧記法近いうちに廃止し,ウィキ互換輪結記法転用する。ハッシュタグ同様,単純に全知検索飛ばすだけだが,他サービスからの移行者デライト触りやすくなったり,デライト向け文書書き直しやすくする効果見込める

大きな用途変更であるため,時印によって適用版存切り替えることになりそうだ。

11日14歩検討方向性定まっていた旧記法導入した昨年3月11日はまだデラング整備最初期で,あまり他サービス他言語との互換性重視しておらず,他サービス採用例多かった二重角括弧による輪結キーボード記法使うことも,独自性を出すのに良いだろうという程度にしか考えていなかった

最近デラングが,デライトにとっての利益損なわない限り他サービス他言語との互換性最大化するという方針になっていることに加え,単純に旧記法視認性の悪さ気になっていたこともあった。最近ではほとんど自分で使っていなかった

[[Ctrl]] のようにキー名長さがあればまだいいが,[[X]] では流石に記号邪魔臭い[_X_] という記法は当時検討した記憶があるが,[X] に対して物足りず決め手に欠ける感じたか,なんとなく見送っていた[[X]] は「キー立体感を表現しているように見えなくもない」希哲15年3月11日2歩思っていたが,<kbd>装体デライトも含めて,四方み,立体感を出すため上境界線よりも下境界線目立たせるという形になることが多いため [_X_] の方がむしろ装体近い

逆括点を使った [`X`] という記法採用例を見かけて悪くない思ったが,まだ普及度低い上,これは `[X]` との書き間違い続出しそうだと感じたたため見送った[_X_] ならその問題もなく,直感性でこれに勝るものはなさそうだ。

<kbd>入れ子にすることも出来るので,[_Ctrl_] + [_X_] のような組み合わせ記法として扱うことを考えたが,実用上大きな変化はないはずなので後回し

{用者}{デライト開発}{デラング}{『希哲日記』}{希哲11年}{手定め}{遠ざかる}{遅らせた意義}{引っかかっていた}{待っていた}...=}(93)

{希哲15年10月27日の日記 K#F85E/E74C-57D7}

昨日開発環境整備一環として消極的に考えていた SLFS 開発の再開だが,献典整備としての可能性もあることに気付き,新生デライト開発とともに再開することを決めた

当然ながら無駄に新生デライト開発圧迫するわけにはいかないので,相乗効果生み出すようにやっていきたい

SLFS希哲11年実用化してから,あえて深追いすることを避けてきた。ほとんどは実用上の問題が生じた時に設定パッケージ引装などを行うくらいで,それも SLFS 開発というよりは用者として使っているという感覚であり,事実上開発停止状態に近かった。

直接収益化結び付けるのは極めて困難予想されたため,パッケージ下信ダウンロード引装インストール手定めにかかる時間最小化するための極力良いネット環境高性能開発機,そして十分な時間用意する必要があると考えていた

SLFS希哲社にとっても大きな財産だったが,自分で使っているだけということに「死蔵」というべきもったいなさ常々感じていた時間の経過とともに忘れていること増え保守性落ちていた。これを改めて実感したのが昨日の核脳カーネル周りの調査だった。

SLFS 開発から遠ざかるようになっておよそ一年後デライト開発に入り,デラングも含めて描出環境描出手法飛躍的な発展遂げ今にいたる。希哲11年に比べ,技術記録もはるかに描き出しやすくなっている金風によって多少の時間的余裕も出来た。

こうした環境の変化によって,気付けば十分な時間対効果見込めるようになっている。SLFS にもようやく世に出せる時が来たということだろう。新生デライト開発の再開前に何かが引っかかっていたが,この時を待っていたのかもしれない。それなら遅らせた意義もある。


昨日に続き5時前起床は出来たが,短時間睡眠続きなので早く寝ることにした。

28日振り返り日記

=}
{見込める}

{}