{戦略的失敗}{軽量標記言語}{サービス固有言語}{Scrapbox}{角括弧}{記法}(6)

{Scrapbox 記法 K#F85E/E74C-A6EF}

全体的に野暮ったい記法が多いという印象があり,宇田川の評価はあまり高くない。ただし,Markdown 一辺倒の風潮に反旗を翻す姿勢には共感できるので,嫌いというわけでもなく,面白い試みとして見ている。

様々な用途で使われる角括弧単独採用してしまったのは戦略的失敗か。

ウィキでよく使われる二重角括弧を冗長という理由で単純化した,というような開発者の話を読んだ記憶があるが,なぜ単独角括弧が避けられたのか,という視点が欠如していた。適切な越化手段があれば補えない欠点ではないが,現時点ではなさそう。

(1){あれ}
{開発}{デラング}{軽量標記言語}{開発記録}{}{輪括弧}{希哲16年6月}{希哲16年7月21日}{開始する}{輪郭小窓実装}(146)

{希哲16年7月21日の開発 K#F85E/E74C-7F30}

無番輪符改良完了した。これでデルン長年の課題だった輪郭間輪結における知番依存解消した作業中輪符補完機能についての閃きがあり,脳爆発始まった


輪郭選り手上での輪符補完機能は,省割キーあるいはカーソルのある輪括弧表示されるボタン押すことで開始することにした。省割キー仮に Ctrl + {想定しておく。

また,これを機にタッチ端末向け記号入力ボタン本格的に検討することにした。軽量標記言語中心とした用合い課題として記号入力煩雑さがあったため,その解決策兼ねる

ここでようやく輪符補完機能実装イメージまとまった最近のデライト開発では最大の暗部になっていた部分で,極めて大きな収穫言える


漠然と輪郭小窓実装含めていた輪符補完機能だが,ここだけ実装イメージまとまらなかった一時後回しにすることを考えていた理由だった。

原因は,輪符補完自動開始前提としていたことだった。自動開始となると入力中デラング正確に解釈する必要があるが,デラング複雑性考えると交度の肥大化避けられそうになかった深刻な保守性の低下請い手低速化懸念される

更に問題なのは,そこまでの実装コスト払っても,用者体験の向上繋がるとは限らないということだった。この手の挙動好き嫌いがかなり分かれる上に環境との相性問題大きい多くの人満足する水準にしようと思えばキリがない

読み込み中...
{デラング}{軽量標記言語}{進捗記録}{}{}{HTML の要素}{記号}{@}{与える}{進捗}(248)

{希哲16年2月15日10歩 K#F85E/E74C-2CA8}

{軽量標記言語}

{}