{圧倒的に}{希哲16年3月16日のツイスト}{希哲16年3月16日}{当時の}{ツイスト}{必ず}{成功体験}{狂った}{勝る}{勝ち}...=}(21)
{用者}{デラング}{進捗記録}{数式記法}{軽量標記言語}{越化参照}{希哲16年2月4日の開発}{希哲16年2月4日21歩}{良い代替案}{深く考えず}...=}(139)

{希哲16年2月4日17歩 K#F85E/A-E74C-503B}

進捗時限記録中略

デラング整備越化記法越化参照疑似実体参照についての検討終了

越化エスケープ基本的な仕様について記法内部実装両面から急速にまとまった

単一文字越化

まず,バックスラッシュ使った単一文字越化では,全ての文字越化することにした。ただし,この「越化」は,「通常とは異なる特殊な解釈試みること」であり,論組言語等でのそれと同様必ずしもデラング記法としての解釈避けることではない。

非特殊文字扱い

軽量標記言語単一文字越化対象非特殊文字に付けた場合の挙動としては,「不明なエスケープシーケンス」などと違了出すわけにはいかないので,以下の2つ考えられる

普段非特殊文字にあえて越化文字を付けてみることなどないので,一般的にどう実装するものなのか分からなかったが,特に定石があるわけではなさそうだ。

当初なんとなく前者想定していたが,この場合,全ての特殊(になりうる)文字予め定義しておく必要があり,挙動変則性用者混乱させる懸念もある。デラングの場合は文脈によって特殊文字になったりならなかったりすることも多いため,その対応も含めるとかなり複雑化してしまう。

後者の方が分かりやすいといえば分かりやすく,先日交度記法出来た代置子方式応用すれば実装単純化出来る。数式記法などでは越化対象文字判別する必要があるが,これは代置子への置換処理の前に制御子置換すればいい。

いずれにせよ後から変更するのが難しい仕様ではないので,まずは実装単純性を取るべきだろう。

数式記法との整合性

越化記法との整合性深く考えずLaTeX 方面の慣習従い導入した数式記法\[ ... \]\( ... \) をどうするかという問題に少し手間取った

これまで越化記法も「デラング記法としての解釈避ける」ためのものとして想定していたが,ここで本来越化という概念立ち返り,「通常とは異なる特殊な解釈試みる」ためのものとすることで整合させることにした。

越化参照

単一文字越化で「越化」という概念捉え直した結果,これまで Dex で「疑似実体参照」と呼んでいたものを「越化参照」として再定義することが出来た。

これに伴い,疑似実体参照では &_foo; としていた記法を,越化直感的に分かりやすい &^foo;統一することにした。代置子&^[連番];,「制御子(ここで命名&^[名前]; となる。

越化用の代置子に関しては &^1; などと書き分けるかと考えたのとほぼ同時に前述越化概念拡張があり,そもそもこれまで「疑似実体参照」と呼んでいたものが越化列役割同じであることに気付いた

参照先実体があるわけではないので「疑似実体参照」という名称にはずっと違和感があったものの,良い代替案見つからなかった。これで越化記法課題同時に解決してしまった。

{HTML}{デラング}{進捗記録}{含まれる}{第三次デライト市場戦略}{第二次デライト市場戦略}{廃止}{越えて}{デライト市場戦略}{Markdown}...=}(187)

{希哲16年1月29日9歩 K#F85E/A-E74C-CC5B}

進捗時限記録中略

デライト市場戦略についての検討終了

デラングによる「対 Markdown 戦略」を市場戦略一環として加えることにした。昨日こんなツイスト書いてみて,デラングデライト市場戦略の中で大きな役割担えることを確信した

デライト市場戦略これまで

デライト市場戦略は,まず対 Roam Research 戦略中核としたところから始まり第二次市場戦略以後は対 Notion 戦略一環位置付けていた。要は,旧来個人知識管理通類限界越えようとするこれらのサービス流行利用して,最も根源的に個人知識管理革新目指すデライト売り込む,という目論見だった。

しかし,英語圏での事情多少異なるようだが,少なくとも日本ではどちらもそこまで大きなうねりにはなっていない。一番勢いのある Notion ですら,まだ「一部界隈の流行」の域を出ていない個人知識管理サービス市場も,全体としてそこまで拡大しているようには見えない

結局のところ,デライト必要になるというのは「既存の個人知識管理通類限界を感じている人」なわけで,その広がってくれることがデライトにとって一番の追い風だ。その当てが外れた格好になっていた。

個人知識管理サービス市場への苛立ち

第二次市場戦略以後は,こうした外部環境への依存から脱却しているので致命的な問題にはならなかったものの,個人知識管理サービス市場の拡大遅さに対する苛立ちというのは常にあった。

個人知識管理サービス」という枠組みこだわるべきではないのかもしれない,とも考えた

極端な話デライトを「ゲーム」として売り込むのはどうかと考えたことすらある。「マインドクラフト」という言葉造ったこともあるが,テキストによる箱庭ゲームと言えなくもないし,ゲームなら独自用語の多さも独特な世界観演出になる。

そこまで行かなくとも,KNS なのだから SNS 方面に売り込むかなどとも考えたが,結局,根想からこれまで練り上げてきたものを考えると,そう簡単な話ではない。中途半端あれこれやればますますややこしいものになってしまう。

個人知識管理サービス市場狭さ越えて

最近デラング整備急速な進展により,他の軽標記言語との比較研究も進む中で,Markdown想像以上に様々な分野浸透していることに気付いた

個人知識管理サービスでいえば,EvernoteNotionRoam Research と,これまでデライト意識することの多かったサービスはほぼ Markdown 対応であり,別種のサービス選り手などへの広がり非常に大きい。つまり,比較対象として,より幅広い関心集められる

これこそ,常々感じていた個人知識管理サービス市場狭さ」を越えていく道筋ではないかと思うようになった。

市場戦略としてのデラング

デラングはもともと「DIL」と呼んでいたデルン最初期から独立した言語だった。というのも,デルン初期実装では今でいう描写に使う言語選択式であり,プルダウンメニューから txtHTML などとともに DIL選択出来る,という設計だった。

ただ,長い描出経験の中でほぼ必要なかったので,単純化志向するデライト中心移行する過程でこの選択方式廃止となった。

この時点で,デラングにも岐路があった。単なる「デライト記法」の内部名称となるか,軽標記言語としてあえて主張するかだ。後者を取ったのは,「デラング」を正式名称として採用することにした昨年3月3日4歩のことだった。

デライト記法」,あるいは当時考えていた描写記法」とすると閉鎖的恣意的なものという印象を与えてしまうが,「デラング」という言語とすることで外向き体系的印象を与える。もちろん,当時から Markdown意識してはいたが,そこまで大きな位置付けではなかった。やはり,デラング整備進展とともに認識深まった感がある

それこそ,デラングMarkdown のように注目を集めるようになったら,デライト多大な利益がもたらされることは考えるまでもない知能増幅サービスとしてのデライト自体よりも,軽標記言語としてのデラングの方がはるかにその役割理解しやすいことを考えれば,そこまで非現実的でもないし,その技術手応え十二分にある。

まだデラング中心の「第四次デライト市場戦略」にすべきというほどの確信があるわけではなく,デラング整備新生デライト開発含まれるので,第三次デライト市場戦略有力武器加わったというところか。

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

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

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

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


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

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

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

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

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

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

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

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

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

=}
{進捗記録}{注意記法}{補足記法}{希哲16年1月20日8歩}{3個}{ややこしくなりそう}{4個}{2個}{記号の数}{直感的な記法}...=}(37)

{希哲16年1月20日4歩 K#F85E/A-E74C-D402}

進捗時限記録前略

補足記法注意記法についての検討終了

概ね以下のような形で実装していくことにした。

??
軽い補足
??

???
重い補足
???

!!
軽い注意書き
!!

!!!
重い注意書き
!!!

終了記号には開始記号のほか区切り線--)を使うことも出来る。また,開始記号に続けてラベル指定出来るようにする。


少し前から,この手の記法導入するとしたらどうするか考えていたが,これ以上直感的な記法無さそうなのでこの方向固めることにした。

記号の数は,2個以上4個未満4個以上軽重基準にしようと思ったが,ややこしくなりそうなので2個3個以上単純化した。

{進捗記録}{出放り}{希哲15年8月31日の開発}{上手く解決}{残さない}{元画像}{転送効率}{保存効率}{又出与え}{希哲15年8月31日の進捗時限}...=}(42)

{希哲15年8月31日12歩 K#F85E/A-E74C-722D}

譜類添付機能における添付画像仕様検討終了

保存効率転送効率観点から,原則として,画像WebP変換することにした。元画像参照出来た方がいいかもしれないとも思っていたが,効率を大きく犠牲にしてまでやる意義はないだろう。

また,Exif も原則として削除することにした。これも迷っていた所だが,無闇情報残さないという考え方の方が描出公開原則調和することに気付いた

cwebp出放り又出与えを削除するため,一石二鳥実装単純化出来る。

また一つ課題上手く解決した。

{`std::string`}{`s_T`}{近像}{Re:「近象」と「遠象」について}{希哲15年8月13日のツイスト}{希哲15年8月13日}{文字列型}{良い例}{変種}{単純な}...=}(43)

{「近象」と「遠象」について K#F85E/A-E74C-B093}

近象」というのは,感覚的身近抽象性のことです。言い換えると,「より単純包括的なもの」,つまり「輪郭」的なもの,ということになります。その反対が「遠象」です。

抽象」は,本来何かのために思考単純化するものですが,必ずしも感覚的近さ意味しません。数学のそれが良い例です。

例えば,「近象文字列」というのは,簡単に言えば「文字列直感的に扱えるように抽象化したもの」です。この直感的というのも厳密には「思いついたように扱えること」という意味で,「直想的」と表現していました。

C++文字列std::string と書きますが,様々な変種もあり,「文字列を扱いたい」という書き手単純な要求に対して直想的ではありませんでした。書き手の頭の中で,「文字列を使うこと」と「std::string を使うこと」の間に距離があるということです。C++ ではライブラリによって異なる文字列型を使い分けることが多々あるので,std::string固有名詞的に文字列を扱う手段の一つとしか認識されていません。

では,s_T として「細かいことはさておき大体の場面で使える文字列型」を提供することにしました。「文字列を使うこと」と「s_T を使うこと」が概念として普通名詞的に)一致するように設計されています。これを「近象文字列」と呼んでいました。

{違了処理整備}{Aejs 整備}{開発}{開発記録}{自動ページ展開機能}{希哲15年7月29日の日記}{一応の解決}{舞覧手定め環境}{LambdaTest}{正式採用}...=}(37)

{希哲15年7月29日の開発 K#F85E/A-E74C-3FD4}

主に輪郭選り手抜控機能整備Aejs 整備も多少進んだ。

まだ荒削りながら,とりあえず描き直しでも描きかけ描写復元出来るようになった。

先日の違了処理整備と併せて,違了誤遷移出与え消失が生じやすいというデライトの課題一応の解決をみて,信頼性大きく向上した。


抜控機能によって自動ページ展開機能無限スクロール機能単純化にもなりそうなことに気付いた。

新規描出フォームをどう見せるかが課題だったが,複数窓で同一画面に同期された新規描出フォームが表示されることに慣れてみると,同一ページにあっても不自然ではないと思える。とりあえず,単純に10輪毎に表示するだけの実装でも良さそうだ。


舞覧手定め環境整備一環として,LambdaTest正式採用決定した。

{単純化}

{}