{完成の域に達した}{表記的}{写し取りたい}{共有目的}{貼り付けたい}{外部媒体}{適当な時期}{整理中}{省略された}{写し取り時}...=}(145)

{希哲16年6月17日の開発 K#F85E/E74C-9EA6}

自我知番省略機能実装終え第二次知番改良完了とした20歩ここでやっておこう思ったのも,途中で第零番節の削除転換したのもあまりにだったが,その割には終始円滑にり,収穫想定はるかに越えて多大だった。全体として大成功言っていいだろう。

第二次知番改良経て知番表記的にも内部的にも完成の域に達した。あとは仕様実装微調整繰り返していく

まず,当初の目的だった知番の簡略化言うまでもなく大きいこれまで一般のデライト用者最短でも K#9-XXXX/A-YYYY という15文字知番輪郭扱う必要があった。それが第零番節の削除によって11文字K#XXXX/YYYY になり,自我知番の省略によって7文字K#/YYYY になった。知番表記仕様に関しては理想的な形だ。

第零番節の省略」から「第零番節の削除」に転換したことで,知番周りの交度出場整理劇的に進んだ。これにより,効率性保守性大幅に向上したのはもちろん,「新括体採番法の完成」という思わぬ収穫繋がった未実装だった自動知番拡張もここで実装出来た今のところ第二番節しか使っていない状況だが,そろそろ必要かという丁度良い時期だった。

波及効果想定以上に大きかった出場見通しの悪さなどが障害になっていた機能実装に関しては大幅な所要時間短縮見込めるようになった特に見通しが悪い課題だった KNEST 隠し出与え構造がこの期間固まり,一気に実装可能性高まった自我知番省略機能Dex との連携必要になったことで,他の記法でも活かせる出与え共有機構整った。これが無番輪符改良などにも繋がっている

将来的に長い知番増えた時のための「知番略記法」を中心とした第三次知番改良方針固まった。この長年の課題にも解決の見通しが立った。

一つ見送ったこともある。自我知番省略された知番写し取り時自我知番付け自輪郭描写欄などへの貼り付け時自我知番の省略をする4月8日の開発記録,というのは,やはり用合いとしては理想的盛り込みたかったが,今回見送った。このあたりの事象Aejs整理中なので,どうしても場当たり的交度になってしまう。他輪郭素出から写し取りたい時や,外部媒体厳密な知番貼り付けたいという時には便利だが,現時点必要としている人少ない共有目的なら共有ボタンがある。交度整理しながら適当な時期実装することにした。

{第二次知番改良}{kno_T}{残しておくべき}{活用出来なかった}{今後の開発}{なりつつあった}{離れていた}{出場周り}{温存する}{望める}...=}(67)

{希哲16年6月8日の開発 K#F85E/E74C-352F}

{👍}{希哲16年4月7日の開発}{希哲16年4月7日の進捗}{ページ遷移無し}{停止する}{フォームの送信}{-webkit-tap-highlight-color}{妙な効果}{タップ時}{用意されている}...=}(75)

{希哲16年4月7日14歩 K#F85E/E74C-D3A9}

進捗時限記録中略

細かい装体調整など。

iOS上のSafariで,横方向での閲覧時に引き入れ輪郭が不自然に大きく表示される」という不具合報告があったが,確かに手元iPhone同様現象があり,気になっていたデライトの不具合にしては不可解なのでもしかしたら舞覧稀なバグなのかと思ったが,再現性があるらしいことが分かったため調査した。

結局諸場舞覧自動拡大機能であり,text-size-adjust-webkit-text-size-adjust)という制御用CSS プロパティまで用意されていることが分かった。以下のようにして解決

-webkit-text-size-adjust: 100%;
text-size-adjust: 100%;

もう一つ諸場舞覧気になっていたことに,輪結ボタンタップ時妙な効果入るというのがあったので,ついでに調べてみると,これも諸場舞覧特有機能で,-webkit-tap-highlight-color不可視出来た


スマホ弄っているうちに,iOSSafari全知検索ボタン動き付け止まっていることに気付いた

これはフォームの送信などで描画処理停止する Safari 特有仕様であることが分かったSafari の問題といえばそうだが,実用上の問題はなく,まともな解決策無さそうなので放っておくことにした。

全知検索整備方針定まったことだし,そろそろページ遷移無し輪郭一覧更新出来るようにしてもいい頃だろう。

=}
{用者}{希哲16年3月12日の開発}{希哲16年3月12日の進捗}{`}{解釈出来る}{完了させた}{中途半端な実装}{使用経験}{書き換えずに済む}{意図の明示}...=}(133)

{希哲16年3月12日7歩 K#F85E/E74C-8A2F}

交度記法改良

以下の作業終えたため,ここでいったん終了

これにより,デラング記法例示洗練された

```txt
これまでのデラング記法の例示
```

``dlng
これからのデラング記法の例示
``

交度部区記法開始記号終了記号については,これまで ``` 固定だったため,交度部区記法内で交度部区記法について例示出来ないという問題があった

行内交度記法逆括点の数を調整出来るようにして1月17日15歩から,この方式統一することを考えていた

これを機に逆括点の数は2個でもとした。区切り線記法最初から Markdown などで一般的な3個以上ではなく2個以上-導入したが,交度部区記法では確信が持てなかった

交度部区記法実装からちょうど一年経ち3個以上でなければならない理由はない,と使用経験から判断したなんなら1個でも解釈上問題はないはずだが,目印としての機能考える2個限度だろう。他の記法との統一感もある。


これまで外部ライブラリhighlight.js任せだった交度部区記法言語名自主的に管理する第一歩として,取り急ぎデラングνS対応した

デラングdelangdlngdlntxt に,cuucppに,νsvsjs に,それぞれ Dex 側で変換するとりあえず大文字小文字区別しない

これまではデラングtxt などと書いていたが,意図の明示という観点から問題があった。これなら今後構文ハイライト対応した時に書き換えずに済む

言語名対応関係については実装委ねるべきかとも考えたが,将来的に混乱の元になりそうな部分なので,対応関係言語仕様規定し,構文ハイライトなどは任意実装とすることにした。

また,用者未定義言語名使用出来るように,例えば ```newlang(oldlang) のように代替言語名指定出来る記法検討開始している


1月17日15歩で,外側逆括点の数を調整出来る仕様にしたが,`` `a` `` のように外側より少ない個数でないと上手く解釈出来ないなど中途半端な実装だったことを思い出し実装完了させた

これで ` ``a`` ` でも `` `a` `` でも `` `a`` でも,対応する逆括点さえ判別出来れば問題なく解釈出来るようになった。


全て手定め出振るい済み

=}
{仕様}

{}