{希哲16年5月18日}{デライト}{なおかつ}{制御しやすい}{握接出来る}{選り手を開く}{操作手順}{複製輪郭}{ボタンを押す}{ずっと考えていた}...=}(117)

{希哲16年5月18日の開発 K#F85E/E74C-2BA8}

長い間課題だった描写拡縮ボタン輪郭複製機能について大きな進展があった。

描写拡縮ボタン

昨日の開発最大化アイコン出来たことをきっかけに,描写拡縮ボタン実装イメージ固まり,実装手定めまで概ね完了した想像以上に早く上手くまとまった下見機能との相性も良い。ただし輪郭選り手抜控機能整備途中であるため未出振るい

描写拡縮機能的には単純だが,用合い特に領当て難しかった最近描写部下境界重ねる形での実装考えていたが,描写部飛び出す他の要素干渉してしまう。かといって余白無駄に広げたくない。これは,下部陰影重ねつつ,初期化時点スクロール可能な場合は下余白追加することで解決した文字暗い背景色重なっても視認出来るように,半透明白背景付けた

拡大ボタンスクロール可能であることの目印としても効果的なので,これを活かしてスクロール完了時には透明度を上げ,それと分かるようにした。

これで,外観操作感ともにデライト調和した描写拡縮ボタン出来た描写部高さ固定一覧性確保するために必要なものだったが,用合い上弊害小さくなかった陰影付きスクロール最大化アイコン,そして描写拡縮ボタンによって,ようやくこの問題解決した

輪郭複製機能

輪郭複製機能課題としてずっと考えていたが,用合い上難しさがあった。

ボタンを押すことで複製輪郭出来る,というのは使用頻度考える誤操作懸念の方が大きい。となると,目立たないように置くしかない。かといって,操作手順増えると,選り手を開いて写し貼りするのと大差ない

簡単に握接出来て,なおかつ制御しやすい用合い必要だった。ここで,「知名描写複製して新規描出フォーム移動するボタン」があればいいことに気付いた。これなら,自輪郭常に表示しておいてもいいだろう。

輪郭選り手では×ボタンがある位置置けそうだ。

{希哲16年3月12日}{希哲16年3月11日}{希哲16年2月}{希哲16年3月12日の開発}{希哲16年3月12日の進捗}{積極的な活用}{完成した}{編み出した}{面白いこと}{どちらも}...=}(143)

{希哲16年3月12日14歩 K#F85E/E74C-2A34}

進捗時限記録中略

今後の Dex 設計方針についての検討終了これから越化参照大活躍しそうだ。


まず,課題だった脚注記法実装方針について検討している内に,越化参照部区間通信活用出来ることに気付いた

部区毎に越化条件変化などがあることから,各記法解釈部区個体任せたい。しかし,脚注記法のように最上位部区との出与え共有必要記法もある。

このような場合単純に考えれば指示体通して部区個体間で変数共有するということになるが,この種の記法増えるたびに目的別指示体増やすのは設計として美しくない汎用的な変数一つ集約するのも,効率性厳密性観点から難がある

ここでふと,越化参照使えることに気付いた下位部区個体中途解釈した記法には目印となる越化参照を付け,上位部区個体変換処理完了させる

これに似た部区間通信手法Dex 初期実装から現 &_skp;使い続けているが,どちらかというと「邪道」だと感じていたため,意図的に応用範囲広げなかった紆余曲折を経て,これが一番単純性効率性保守性バランスが良いということが分かった

これで脚注記法目次記法実装容易になった。他にも,輪郭情報参照必要記法など,部区間通信必要場面全般越化参照活用出来るだろう。


もう一つ,処理済み対象識別に関しても進展があった。

1月21日4歩で,&_tgt;&_fin; のような目印付加することを考えていたが,付加的越化参照では結局正規表現の複雑化避けられないため,実用化出来ていなかった

昨日終えた客体表現への書き換えDex 初期実装交度整理している時,再置換避けるため記法一部越化参照当時の疑似実体参照置換する手法使っていたことを思い出した。これもあまり積極的に応用範囲広げなかった手法だが,思っていたより合理的であることに気付いた

例えばhttp&_http; のように一時的に置換してしまえばいい。考えてみれば単純なことだが,灯台下暗しのごとく単純なこと真価理解するには時間がかかるということを改めて学んだ経験不足だと,どうしてもより高度そうなことに目移りしてしまう。


面白いことに,どちらも原点回帰のような発見だった。

直感編み出した Dex 初期実装手法再評価する十分な経験出来たこともあるが,「越化参照」という概念完成し積極的な活用考えられるようになったことも大きいのだろう。中途半端だった「疑似実体参照」から発展したのはつい先月のことだ。

{希哲16年3月12日}{👍}{用者}{希哲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`` でも,対応する逆括点さえ判別出来れば問題なく解釈出来るようになった。


全て手定め出振るい済み

{希哲16年2月13日}{日記}{デライト}{希哲館事業}{『希哲日記』}{越えて}{持つ}{はるかに}{加速させ続ける}{夢のまた夢}...=}(115)

{希哲16年2月13日の日記 K#F85E/E74C-DA33}

デライトも2周年迎えた希哲14年2月13日24時15分なんとかデライト正式離立漕ぎ着けた時の生々しい感覚は今でもよく覚えている

今日を「デライトの早期成功」の目安としたのは昨年9月7日金風起こるわずか11日前のことだ9月7日の日記金風状況整理困難になった後は,組計上ほとんど唯一目印になっていた。

そして今,デライト非常に評価難しい状況にある。手放し成功と言うには収益額低過ぎるが,不成功と言うにはあまりにも理想的な状況にある。

金風後に「デライト収益目標達成」を「デライト収益乗軌化」に改め一時的な収益額よりも持続的な成長軌道乗せることを重視するようになった11月1日の日記。その点に限れば成功した言えなくもない当時の想定より低過ぎる収益額にもかかわらずそう思えるのは,金風がそれだけの時間稼ぎをしてくれたからでもあり,目先金銭以外の収穫想定はるかに越えて多大だったからでもある。

今のところ,デライトにも希哲館事業にも不安はない。とっくに収益面以外では理想的な状態にあったのだから,まさに「鬼に金棒」だ。

今は黄金状態極力維持し黄金循環加速させ続けることくらいしか新しい目標思い付かない。もう人類の限界というか物理的な限界に近い気がするので,これ以上無理をしても早死にするだけだろう。


成功したのかどうか,考えようとすると訳が分からなくなってくるが,とりあえず気分最高だ。

それを象徴するかのように,今日は“空を飛ぶ夢”から目覚めた人間ばたばたさせるとのように飛べる世界で,仲間混じって自分もやっと飛べた,という新鮮な夢だった。

昔から希哲館事業背負う自分は飛べそうで飛べない幼鳥みたいなものだと思っていた。それはもどかしさでもあり,嬉しさでもあった。何せ,希望持つことすら絶望的な事業として始まったのだから,飛び立つ希望持てるだけで奇跡のようだった。

それが本当に飛べるようになるというのは,奇跡の先の奇跡夢のまた夢現実になるようなことだ。今は訳が分からなくて当然なのだろう。

=}
{希哲16年1月20日}{日本語}{デラング}{ラテン文字}{進捗記録}{パンくず記法}{注意記法}{補足記法}{折り畳み記法}{感じさせてくれる}...=}(166)

{希哲16年1月20日8歩 K#F85E/E74C-2FC4}

進捗時限記録中略

ひょんなことから予てから課題だった折り畳み記法急速にまとまった

折り畳み記法は,他の部区記法組み合わせ使える汎用的な記法として実装していくことにした。以下のように,部区開始行末^加えることで,その部区見出しなら階層下内容折り畳まれるようにする。厳密に言えば見出し階層下内容含む部区ではないが,例外的に扱う

・リストの折り畳み ^
  ・折り畳まれる項目

* 折り畳む見出し ^
折り畳まれる内容

+{埋め込みの折り畳み K#XXXX} ^

検討中,これがネタバレNSFW のような閲覧注意内容使えそうなことにも気付いた

きっかけからまとまるまで

補足記法・注意記法についての検討で,終了記号区切り線--)も使えるようにすることを考えた時,以下のように区切り線亜種として ^^ を使って折り畳めることをしてもいいのではないかと思い付いたことがきっかけだった。

?? 補足
補足内容
^^

この終了記号のように,他の部区にも統一的に応用出来る記法があれば何かと可能性が広がる。そこであれこれ検討してみると,部区終了記号だけでなく開始記号側にも分かりやすい目印欲しくなった。むしろそちらの方が自然場合多い

^対応する記号なら v考えられるが, などと異なり自然言語扱うデラングラテン文字導入しにくい日本語はともかく外国語問題が起きないとも限らない

何より下向きの三角形一般に展開されていることを表す記号なので,折り畳まれている記号として v開始記号添えるのは直感的ではない。となると,<>デラングではある程度活用方向性決まっているので,矢印的に使えそうASCII 記号^ しかない。

ここで,「行末^」を思いついた。これなら折り畳み記号としての直感性もあり,他記法とも組み合わせやすいパンくず記法で「行末>」を採用する直前にあっただが,微妙な違和感があり回避していた。この直感大当たりだった。

そして終了記号^^ とも整合的見える……と考え出したところで,今度はこっちの問題気になってきた。まず,日本人感覚ではぱっと見顔文字見える。そこで,--亜種であることが分かりやすいように --^考えてみたが,空行挟まない特定の文字指しているような記号見える

そもそも開始行末1個あれば,特別な終了記号要らないことに気付くまで時間はかからなかった結果的に非常にすっきりしたになった。

他の検討案

昨年6月18日の開発時点からは,以下2案があった。

++ ラベル
折り畳まれる内容
--

? ラベル
折り畳まれる内容
!

前者がこれまでの最新案で,区切り線--対応させて,++使うツリー開閉記号しばしば +-使われることに引っかけただったが,埋め込み記法渡括記法との紛らわしさから現時点での採用考えにくい。特に最近では ++使った行内埋め込み記法有力視していることもあった。無理に区別出来なくはないが,意味的な整合性確保するのが難しい

後者は,補足記法注意記法方向性固まった今となっては採用余地皆無だが,当時から今回の検討きっかけになった補足記法との組み合わせ考えていたことを示すであり,歴史的な意義感じさせてくれるものではある。

{希哲16年1月15日}{進捗記録}{目出し輪符の匿名化}{目出し輪符}{使えてもいい}{ありそう}{実用的な}{;}}{:}}{{;}...=}(50)

{希哲16年1月15日14歩 K#F85E/E74C-8E46}

(書きかけ)

進捗時限記録中略

類型化正規表現 rgx_IKON_T整理しつつ,目出し輪符実装出振るい手定め済み目出し輪符手定めの様子

5日5歩検討下敷きにしたが,これも実際使ってみる想像以上収穫だった。

使ってみるまで,前後両方表示するのは遊びくらいかと思っていたが,文中使う時の目印など実用的な使い道意外にありそうだ。

面白い閃きもあった。顔文字して {::}使うなら,ウインク型の {;;}使えてもいいとは思っていたが,これが出放りアイコン使えることに気付いたアイコン表示したいが利用者固有のものである必要はない,あるいは少し不都合がある場合に使える顔文字にもぴったりだ。


この手応えで類型化正規表現は漸次的に行っていくことにした。

{希哲16年1月12日}{希哲16年1月11日}{出振るい}{開発}{開発記録}{パンくず記法}{否定正規表現}{キーボード記法}{希哲16年1月11日の日記}{検索上}...=}(84)

{希哲16年1月11日の開発 K#F85E/E74C-4D6E}

今回適当に調整するだけで済ませよう思っていた行内交度における越化だが,内容をいったん代置子置き換え最後に戻すという「代置子方式」を思い付き一気に書き直した。これで越化処理見通し良くまとまり,一つ課題片付いた出振るい明日持ち越し

単純な手法なのでデラング整備最初の方思い付いてはいたのだが,まだ Dex 実装が出来て間もない時期役割分担未整理な所が多かったため,すっきり実装出来るイメージ湧かず否定正規表現利用するという方針にしていた希哲15年7月9日1歩。ただ,これも再考するとなかなか回りくどいDex 実装も十分に整理され,取り扱いにも慣れた所で,一番単純な手法回帰することになった。

退避させる文字列配列部区個体に持たせる形で,体系的に Dex組み込めた行内交度だけでなく,範囲越化必要場面一般応用出来る。


Dex では,置換処理過程適当な目印必要場合&&foo; のような疑似実体参照とでもいうべきものを使っていたが,検索上紛らわしいことがあり通常実体参照部分一致するなど)論理演算子とも被るため,&_foo;統一していくことにした。順次置換する。


ほか,パンくず記法10歩キーボード記法14歩についての再検討でも進展

{目印}

{}