{文字サイズ}{進捗記録}{目立たな過ぎる}{装体の調整}{読みにくさ}{短い URL}{事情が異なる}{ちょっと長い}{文書の傾向}{検討していた}...=}(94)

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

デライト装体調整URL 装体調整終了

直書き 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年12月13日の開発}{冗長過ぎる}{application/x-kn-acv}{揺らいだ}{KNIF_ 接頭子}{KFF- 接頭子}{KFF}{KN-ACV}...=}(113)

{希哲15年12月13日4歩 K#F85E/E74C-143E}

アンダースコア略記法内包子におけるアンダースコア記法廃止についての検討終了

現状譜類名(例:._acv台録名(例:/_kn/駒手名(例:_knなどにアンダースコア接頭子略記法として多用していた時期名残り多くあるが,ほとんど活用していないため,いったん廃止することを決めた

アンダースコア略記法やその応用記法問題は,明示性簡潔性ともに中途半端で,現実には使いにくいというにある。より簡潔な記法冗長な記法があると使い分け方無駄増えややこしいし,使い所無い

知機駒手では大分前から _kn よりも kn使うようになっているが,9月9日13歩以後はこの kn省けるようにしたため,_出番完全に無くなってしまった結局 _ よりも kn使ってしまう理由は,どうせ面倒臭いなら分かりやすい方が良い,ということだった気がする

これまでの経験上十分明示的な冗長記法短縮記法2つまとめていくのが一番良さそうだ。


KNIF使っていたアンダースコア記法廃止し,代わりに kn- 接頭子導入することを決めた

例えば,これまでの ._acv冗長表記.kn-acv短縮表記.acv となる。知機駒手同様,混同の恐れが無い場合は原則として短縮表記用いる

.kn.acv のようにすることも考えたが,一つの拡張子として認識されないと不都合なこともあるので,MIME 型application/x-kn-acv正式名称初期合わせるKNIF の各形式与える正式名称は,旧称 KFF の時は KFF- 接頭子KNIF になってから KN-ACV のような KN- 接頭子になり,一時 KNIF_ 接頭子揺らいだこともあったが冗長過ぎる,これを機に KN- 接頭子確定する


アンダースコア記法依存した実装排除しながら段階的置換進めていく

=}
{出振るい}{進捗記録}{希哲15年9月13日の開発}{デマングリング}{改良の余地}{pkill -11}{容易に}{異常終了時}{セグメンテーション違反}{std::set_terminate()}...=}(42)

{希哲15年9月13日18歩 K#F85E/E74C-1C7F}

デバッグ環境整備終了

少しだが,std::set_terminate()signal()SIGSEGVバックトレース出力するようにした。これで,セグメンテーション違反例外での異常終了時状況容易に把握出来るようになった。出力録保存機能との相性抜群だろう。

早く出与えを得たいので出振るいしておいた。pkill -11 でしっかり記録出来ていることも確認した。

まだ細部改良の余地はあるが,少しずつ調整していく。


backtrace()C ライブラリなのでマングリングされたシンボル出力されるが,デマングリングが少し面倒臭いので一応そのままにしておいた。大体の意味は分かるし,c++filt を通せば翻訳出来る。

=}
{Markdown}{普及要因}{あれ}{希哲15年4月27日のツイスト}{希哲15年4月27日}{Markdown.pl}{不満点}{面倒臭い}{ツイスト}{記法}...=}(15)
{希哲15年3月1日}{耳慣れない}{良し悪し}{希哲15年3月1日のツイスト}{能否}{面倒臭い}{ツイスト}{直感的}{情技}{拡大解釈}...=}(18)
{進捗記録}{廃止}{デライト}{希哲14年9月22日の開発}{scroll-behavior: smooth}{スムーススクロール}{最下部}{ページ内}{希哲14年9月22日の進捗時限}{希哲14年9月22日の進捗}...=}(44)

{希哲14年9月22日6歩 K#F85E/5B28-3448}

デライト用合い改良

途中で終了。

現状,デライトではページ内移動が若干面倒臭いページャー最上部最下部への輪結も置くことを考える。

新規描出フォームへの輪結は別で考えていたが,最下部への移動と役割が被るため,+ を組み合わせたアイコンを加えることにした。

下部ページャーには同様に 検索アイコンを組み合わせた輪結を置く。

これらは画面幅余裕がある時は余白固定表示してもいいだろう。

新全知検索から背景ダブルクリック新規描出フォームを画面下部に固定表示する機能があるが,意外と使わない。他の輪郭を参照しながら書きやすいのではないかと思っていたが,複数に比べて中途半端なせいか。いずれにせよ開いている編集欄の内容は画面遷移をしても持ち越せるようになるため,これは廃止し,画面下部への移動にすることにした。

検索窓の固定表示も以前はあったが廃止し,あまり困っていない。輪郭一覧の長さは高が知れているので,スクロールで行き来しやすいのかもしれない。

単純化のためにも,表示様式を増やしたくない。移動用の輪結を置くだけの方が一貫している。例えば,何らかの操作で新規描出フォームがポンと出てくるより,画面最下部にスクロールさせた方が用者は「描出フォームは常に最下部にあるもの」と全体像を理解しやすい。

ここでスムーススクロール実装を考えるが,とりあえずは scroll-behavior: smooth十分だろう。Safari 等で動かないという問題はあるが,補助的な視覚効果にそこまで手間をかけたくない。

=}
{希哲14年9月12日}{希哲14年9月12日のツイスト}{& ボタン}{面倒臭い}{ツイスト}=}(5)
{面倒臭い}

{}