たまにある https://example.com/https://example.com/
のような URL を含む URL が上手く扱えなかった問題などを越化参照を使って解消。

{希哲16年6月3日19歩 K#F85E/E74C-9A63}

{希哲16年5月30日の開発 K#F85E/E74C-DB91}
自動ページ展開機能実装が一段落した。細部に課題はあるが,実用出来る水準に達した。出振るい・手定め済み。
これに伴い,正式離立前に試していた全知検索窓や新規描出フォームの固定表示を復活させる検討も大きく進んだ。また,輪郭一覧の動的追加の仕組みを整えたことで,検索や新規描出時にも応用出来るようになった。輪郭一覧の更新が効率的に行えるようになり,高速化にも大きく貢献するだろう。
AutoPagerize 対応をどうするかというのが難しい問題だったが,これは挿入を監視して削除,注意書きを表示する方向に落ち着いた。最初以外 .autopagerize_page_element
に display: none
を設定しておくことで表示には影響しない。
AutoPagerize は,ウェブ利用者全体ではわずかな利用率だが,デライト用者が使っているのを見て私自身が使うようになったというのもあり,用者層の重なりは小さくない。出来るだけ混乱させないようにしたかった。
今後,広告の調整が重要になってくるため,ここで運営者・開発者向けにダミー広告を表示する仕組みを整えた(ダミー広告の様子)。
AdSense は,設置者によるクリックはもちろん無闇に表示させることも避けるべきとされているので,これまでは単に非表示にしていた。
機能的に自動ページ展開機能と似たところがある描写後略機能の実装方針検討もほぼ完了。
内容の高さが高さ制限に足りない場合どうするかが最後の課題だったが,これは舞覧側で追加取得すればいいことに気付いて解決した。

{希哲16年4月8日10歩 K#F85E/E74C-ED30}
resize: vertical
}{高過ぎず}...
{希哲16年3月30日の開発 K#F85E/E74C-7061}
描写欄の高さの問題をきっかけに自動リサイズ機能と字数計の実装が出来た。ほか装体調整など。
自動リサイズ機能
旧輪郭選り手では,描写欄の出放りの高さを新規描出フォームで10em,再描出フォームで15emとしていたが,新輪郭選り手ではたまたま15emで統一されていた(画面撮り)。10emでは長文が書きにくいのでこれはこれでいいかと思ったが,やはり新規描出フォームは一言だけや知名だけの描出に使うことも多いためこの高さでは邪魔臭い。
ここで,予てからぼんやり検討していた自動リサイズ機能の導入を考えた。一応 resize: vertical
は設定してあるが,万能ではない。10emから20em程度までの範囲で,改行毎に自動リサイズさせる。導入予定の字数計では字数情報が必要になるため,一緒に行数も保持させることにした。
実際に試してみると,1em刻みでも2em刻みでも違和感があったため,10emから19emまで1.5em刻みでリサイズするようにした(画面撮り:初期状態,最大自動リサイズ)。19emだと個人機でも低過ぎず高過ぎず,スマートフォンの縦向きで柔品キーボードを表示させてもちょうど収まる程度の高さになる。折り返しの多い1行もありうるため,厳密にするなら字数も考えるべきだが,とりあえずはこれで様子を見ることにした。
再描出フォームに関しては,さほど目立つものでもなく,描写部の高さに合わせて描写欄が開くようになっている現仕様が悪くないので,現状維持で様子見しておく。
字数計
字数・行数の保持が出来たことで字数計も難無く実装出来た。描出ボタンか時印の左側に邪魔にならないように表示させてみた(字数計の様子)。
下見の字数と分けようかと思っていたが,下見を開いている時は下見の字数に置換すれば十分であることに気付いた。一応,見分けが付くように頭に「→」を付けるようにした。
これも,厳密に考えると特殊な文字符号などを考慮する必要があるが,キリがないのでとりあえず .length
による概算でよしとしておく。
字数計は,地味ながら意外に需要があることを市場調査を通して知った。自分でもたまに欲しくなることがあった。
txt
}{希哲16年3月12日}{希哲16年3月12日の進捗時限}{駒手記法}...
{希哲16年3月12日12歩 K#F85E/E74C-D53F}
`
}{解釈出来る}{完了させた}{中途半端な実装}{使用経験}{書き換えずに済む}{意図の明示}...
{希哲16年3月12日7歩 K#F85E/E74C-8A2F}
```txt
これまでのデラング記法の例示
```
``dlng
これからのデラング記法の例示
``
交度部区記法の開始記号・終了記号については,これまで ```
固定だったため,交度部区記法内で交度部区記法について例示出来ないという問題があった。
行内交度記法で逆括点の数を調整出来るようにして(1月17日15歩)から,この方式で統一することを考えていた。
これを機に,逆括点の数は2個でも可とした。区切り線記法は最初から Markdown などで一般的な3個以上ではなく2個以上の -
で導入したが,交度部区記法では確信が持てなかった。
交度部区記法実装からちょうど一年経ち,3個以上でなければならない理由はない,と使用経験から判断した。なんなら1個でも解釈上の問題はないはずだが,目印としての機能を考えると2個が限度だろう。他の記法との統一感もある。
これまで外部ライブラリ(highlight.js)任せだった交度部区記法の言語名を自主的に管理する第一歩として,取り急ぎデラング,Cμ,νS に対応した。
デラング
,delang
,dlng
,dln
を txt
に,cμ
,cu
,u
を cpp
に,νs
,vs
を js
に,それぞれ Dex 側で変換する。とりあえず大文字小文字は区別しない。
これまではデラングを txt
などと書いていたが,意図の明示という観点から問題があった。これなら今後構文ハイライトに対応した時に書き換えずに済む。
言語名の対応関係については実装に委ねるべきかとも考えたが,将来的に混乱の元になりそうな部分なので,対応関係は言語仕様で規定し,構文ハイライトなどは任意実装とすることにした。
また,用者が未定義の言語名を使用出来るように,例えば ```newlang(oldlang)
のように代替言語名を指定出来る記法の検討も開始している。
1月17日15歩で,外側の逆括点の数を調整出来る仕様にしたが,`` `a` ``
のように外側より少ない個数でないと上手く解釈出来ないなど中途半端な実装だったことを思い出し,実装を完了させた。
これで ` ``a`` `
でも `` `a` ``
でも `` `a``
でも,対応する逆括点さえ判別出来れば問題なく解釈出来るようになった。
[
}{}
}{{
}{`
}{#
}{必要性が高かった}{*
}{"
}...
{希哲16年3月10日11歩 K#F85E/E74C-521D}
[v]
}{後に}{未チェック}{[X]
}...
{希哲16年3月8日7歩 K#F85E/E74C-9F20}

{希哲16年3月8日2歩 K#F85E/E74C-B5F9}
Cμ 文字列処理改良,rgx_T
の置換道手の引数順序変更,客体表現への書き換え。
箇条書き記法の客体表現化も完了した。あとはルビ記法の客体表現化と,細かい正規表現を点検・修正すれば客体表現への書き換えは完了する。
ここで,箇条書き記法では輩符と数字・ピリオドの後にスペースを必須とするように厳密化した。
負数や駒手応付,小数点などが行頭にあると箇条書き記法として認識されてしまうという初歩的な問題があったが,個人的には,数値も含めて大抵の語を輪符で書いていたため気付くのが遅れた。
用者の指摘で気付いてからも,やや正規表現が複雑化していた部分で,中黒対応も含めると更なる複雑化を招く恐れがあり後回しにしていた。ここで上手く整理出来た。
silver
}{dimgray
}{black
}{希哲16年3月1日}{進捗記録}{希哲16年3月1日の開発}{希哲16年3月1日の進捗}{bottom
}{救われた}{気になって}...
{希哲16年3月1日7歩 K#F85E/E74C-D3B3}
前次部区装体では高さが固定されているため,ルビが含まれると下にはみだしていたが,昨日の装体調整後のパンくず記法でも似た問題があることに気付いた(区切り記号が上にずれる)。
前次部区に関しては Dex でルビ記法の有無を判定して調整するかと考えていたが,ここで,両方とも position: absolute
と bottom
で揃えればいいことに気付き,早速修正した。なんとなく気になって始めたパンくず部区装体調整に救われた。
ついでに,パンくず部区の中間区切り記号の色を dimgray
から black
に戻した(実装初期にも同じことをしていた:1月15日1歩)。表示環境によっては末尾の silver
と見分けにくい。線の太さなどを変えてみてもやはりしっくり来ない。
