
{希哲16年1月29日9歩 K#F85E/E74C-CC5B}
デラングによる「対 Markdown 戦略」を市場戦略の一環として加えることにした。昨日こんなツイストを書いてみて,デラングがデライト市場戦略の中で大きな役割を担えることを確信した。
デライト市場戦略のこれまで
デライト市場戦略は,まず対 Roam Research 戦略を中核としたところから始まり,第二次市場戦略以後は対 Notion 戦略を一環と位置付けていた。要は,旧来の個人知識管理通類の限界を越えようとするこれらのサービスの流行を利用して,最も根源的に個人知識管理の革新を目指すデライトを売り込む,という目論見だった。
しかし,英語圏での事情は多少異なるようだが,少なくとも日本ではどちらもそこまで大きなうねりにはなっていない。一番勢いのある Notion ですら,まだ「一部界隈の流行」の域を出ていない。個人知識管理サービス市場も,全体としてそこまで拡大しているようには見えない。
結局のところ,デライトが必要になる層というのは「既存の個人知識管理通類に限界を感じている人」なわけで,その層が広がってくれることがデライトにとって一番の追い風だ。その当てが外れた格好になっていた。
個人知識管理サービス市場への苛立ち
第二次市場戦略以後は,こうした外部環境への依存から脱却しているので致命的な問題にはならなかったものの,個人知識管理サービス市場の拡大の遅さに対する苛立ちというのは常にあった。
「個人知識管理サービス」という枠組みにこだわるべきではないのかもしれない,とも考えた。
極端な話,デライトを「ゲーム」として売り込むのはどうかと考えたことすらある。「マインドクラフト」という言葉を造ったこともあるが,テキストによる箱庭ゲームと言えなくもないし,ゲームなら独自用語の多さも独特な世界観も演出になる。
そこまで行かなくとも,KNS なのだから SNS 方面に売り込むかなどとも考えたが,結局,根想からこれまで練り上げてきたものを考えると,そう簡単な話ではない。中途半端にあれこれやればますますややこしいものになってしまう。
個人知識管理サービス市場の狭さを越えて
最近のデラング整備の急速な進展により,他の軽標記言語との比較研究も進む中で,Markdown が想像以上に様々な分野に浸透していることに気付いた。
個人知識管理サービスでいえば,Evernote,Notion,Roam Research と,これまでデライトが意識することの多かったサービスはほぼ Markdown 対応であり,別種のサービスや選り手などへの広がりも非常に大きい。つまり,比較対象として,より幅広い層の関心を集められる。
これこそ,常々感じていた「個人知識管理サービス市場の狭さ」を越えていく道筋ではないかと思うようになった。
市場戦略としてのデラング
デラングはもともと「DIL」と呼んでいたデルン最初期から独立した言語だった。というのも,デルン初期実装では今でいう描写に使う言語は選択式であり,プルダウンメニューから txt や HTML などとともに DIL が選択出来る,という設計だった。
ただ,長い描出経験の中でほぼ必要なかったので,単純化を志向するデライト中心に移行する過程でこの選択方式は廃止となった。
この時点で,デラングにも岐路があった。単なる「デライト記法」の内部名称となるか,軽標記言語としてあえて主張するかだ。後者を取ったのは,「デラング」を正式名称として採用することにした昨年3月3日4歩のことだった。
「デライト記法」,あるいは当時考えていた「描写記法」とすると閉鎖的で恣意的なものという印象を与えてしまうが,「デラング」という言語とすることで外向きで体系的な印象を与える。もちろん,当時から Markdown を意識してはいたが,そこまで大きな位置付けではなかった。やはり,デラング整備の進展とともに認識が深まった感がある。
それこそ,デラングが Markdown のように注目を集めるようになったら,デライトに多大な利益がもたらされることは考えるまでもない。知能増幅サービスとしてのデライト自体よりも,軽標記言語としてのデラングの方がはるかにその役割が理解しやすいことを考えれば,そこまで非現実的な話でもないし,その技術も手応えも十二分にある。
まだデラング中心の「第四次デライト市場戦略」にすべきというほどの確信があるわけではなく,デラング整備は新生デライト開発に含まれるので,第三次デライト市場戦略に有力な武器が加わったというところか。
dg_nxt()
}{dg_prv()
}{デラング}{進捗記録}{廃止}{前次記法}{パンくず記法}{自動取得機能}{取得する}{早い段階}...
{希哲16年1月25日12歩 K#F85E/E74C-B0DB}
ふと思い付いて時間的な前後関係を表現する「前後記法」についてまとめた。直感性と既存記法との整合性を考えると以下のような形になりそうだ。
前 <|> 後
前 <|
|> 後
デルンには早い段階で自動的にこのような輪郭を取得する機能があり,月庭では表示させていた時期もあった。前景輪と時印を組み合わせて絞り込む方法だったが,描き手の意図を反映しにくく実行コストは高かったので開発中に無効化し,以来その時期の名残りの交度だけが残っている状態だった(DG_T::prv()
, DG_T::nxt()
,dg_prv()
,dg_nxt()
など)。
パンくず記法同様,これもデラングで解決すべき問題なのだろう。この方向で問題なければ自動取得機能は完全に廃止・削除してもよさそうだ。また思わぬ収穫だった。

{希哲16年1月17日17歩 K#F85E/E74C-835A}
従来の二重角括弧を使った [[X]]
記法に加え,アンダースコアを組み合わせた [_X_]
記法を使えるようにした。
旧記法は近いうちに廃止し,ウィキ互換の輪結記法に転用する。ハッシュタグ同様,単純に全知検索に飛ばすだけだが,他サービスからの移行者がデライトに触りやすくなったり,デライト向けに文書を書き直しやすくする効果が見込める。
大きな用途の変更であるため,時印によって適用版存を切り替えることになりそうだ。
11日14歩の検討で方向性は定まっていた。旧記法を導入した昨年3月11日はまだデラング整備の最初期で,あまり他サービス・他言語との互換性は重視しておらず,他サービスで採用例の多かった二重角括弧による輪結をキーボード記法に使うことも,独自性を出すのに良いだろうという程度にしか考えていなかった。
最近のデラングが,デライトにとっての利益を損なわない限り他サービス・他言語との互換性を最大化するという方針になっていることに加え,単純に旧記法の視認性の悪さが気になっていたこともあった。最近ではほとんど自分で使っていなかった。
[[Ctrl]]
のようにキー名に長さがあればまだいいが,[[X]]
では流石に記号が邪魔臭い。[_X_]
という記法は当時検討した記憶があるが,[X]
に対して物足りず決め手に欠けると感じたか,なんとなく見送っていた。[[X]]
は「キーの立体感を表現しているように見えなくもない」(希哲15年3月11日2歩)と思っていたが,<kbd>
の装体はデライトも含めて,四方を線で囲み,立体感を出すため上境界線よりも下境界線を目立たせるという形になることが多いため [_X_]
の方がむしろ装体に近い。
逆括点を使った [`X`]
という記法の採用例を見かけて悪くないと思ったが,まだ普及度も低い上,これは `[X]`
との書き間違いが続出しそうだと感じたたため見送った。[_X_]
ならその問題もなく,直感性でこれに勝るものはなさそうだ。
<kbd>
は入れ子にすることも出来るので,[_Ctrl_] + [_X_]
のような組み合わせも記法として扱うことを考えたが,実用上大きな変化はないはずなので後回し。

{希哲15年12月18日9歩 K#F85E/E74C-532A}
ここでアンダースコア略記法の廃止に伴う ._/
の廃止,.kn/
への移行作業を始める。.kn/
は .is/
を単純に置き換えたもので ._/
採用以前の隠れ台録だったが,希哲13年頃から復活を考えるようになり(希哲13年2月1日の開発),kn ntf
の実装で試験的に復活させたこともあった。この経緯から,本台録には ~/.kn/
が残っていた。
自我台録 ~/K#/
にも ._/
を置いていたが,よく考えると特殊台録であることが自明な台録を隠れ台録にする必要はないので,~/K#/._/ath/
は ~/K#/ath/
のように普通に置くことにした。
.kn/
は任意の非司組台録に知機関連の出与えを置くために使い,~/K#/
は自我に紐付いた出与えを,~/.kn/
には自我に依存しない出与えを置くというように使い分ける。

{希哲15年12月17日2歩 K#F85E/E74C-7E64}
+ 接尾子を使った台録構造について見直した結果,これまで必ず置いていた各実行譜類への疎輪結のみ「必要に応じて」とすることで概ね現状維持となった。
アンダースコア略記法の廃止により,今後は kn+/foo+/bar.sh
のような台録構造で副駒手を管理することになる。いっそのことこの + 接尾子も廃止していいかと思ったが,kn+/foo
という無拡張子疎輪結を使うことでスクリプト実装(.sh
)とバイナリ実装(.x
)の切り替えが容易になるという狙いがあり,これはこれで捨て難い。設定譜類より直接的で分かりやすいし,最上位は kn
と kn+/
になるのが自然なのでそれに整合的でもある。
将来的に膨大な副駒手を追加することを考えて持たせた柔軟性だが,これまでの実装では無拡張子疎輪結を通して副駒手を探索していたため,常に各副駒手に疎輪結しておく必要があり,スクリプト実装しかない現状ではただ煩雑なだけだった。これを省けるようにすれば柔軟性は維持しながらかなり見通しが良くなる。
/kn/K#F85E/x/
}{隠れ譜台}...
{希哲15年12月15日8歩 K#F85E/E74C-E363}
アンダースコア略記法の廃止のため疎輪結 ~/_kn/
と更にその疎輪結 ~/_/
を削除。輪結先 /_kn/K#F85E/x/
は /kn/K#F85E/x/
に移動済みなので既に機能していない。
構造化台録(x/
)も廃止し,譜台構成を自由にするのは本台録,自我台録以下は知番台録・知番譜類・隠れ譜台のみに限定することにした。これで使い分けが明確になる。知番台録と疎輪結があれば構成はどうにでもなるだろう。
/kn/K#F85E/x/
は「旧 /kn/K#F85E/x/
」として知番台録にし,~/+/x/
から輪結しておくことにした。
~/+/
も廃止を検討したが,やはり省割台録として分かりやすいので存置。

{希哲15年12月13日5歩 K#F85E/E74C-194C}
第零番節については,非表示化や廃止も含めて何度か考えたが,一意性に含めない単なる付加情報として原則省略可能にする方向で検討を進めることにした。常に表示されているものなので簡潔であるに越したことはないし,第零番節を表記することで知番の種別を明示出来る利点も残せる。これも新生デライトの付徴になりそうだ。
将来的な拡張や柔軟な運用のために残していた冗長性だが,デルン/デライトの方向性も定まり,問題ないだろうと思えるようになった。一意性の要素を減らすのは不可能なことがあるが,加えるのは出来なくもないので,全く不可逆な変更というわけでもない。自我知番の重複になると出来なくなるため,やるなら用者数が少ない今しかない。

{希哲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- 接頭子で確定する。
アンダースコア記法に依存した実装を排除しながら段階的に置換を進めていく。
