{区別}(1)
{進捗記録}{}{末尾}{曖昧}{進捗}{希哲16年1月24日}{文字装飾記法}{<small>}{置き換えられる}{補足部区}(73)

{希哲16年1月24日16歩 K#F85E/E74C-1FEF}

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

4歩を以下のように修正した。強調度に応じて三段階となる補足記法同様

!--
小さな注意書き
--

!!--
通常の注意書き
--

!!!--
重要な注意書き
--

装体は,23日2歩下敷きに,境界線背景色無しで font-size: 0.8em 程度にした小書きのものを加える。この場合,一段階目注意部区補足部区装体的に区別出来なくなるが,そもそも小さな注意書き補足違い曖昧なものなので自然といえば自然だ。

読み込み中...
{デラング}{進捗記録}{}{}{記号}{自然言語}{日本語}{ラテン文字}{v}{-}(166)

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

進捗時限記録中略

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

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

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

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

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

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

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

読み込み中...
{開発}{Markdown}{開発記録}{方向}{一段落}{全角}{半角}{デライト}{HTML}{AsciiDoc}(84)

{希哲15年5月15日の開発 K#F85E/E74C-16DE}

デラング整備見出し記法実装

見出し記法一段落

見出し記法実装に関しては一段落したデライト公式での解説

結果的に,Org-Mode,主要なウィキ実装AsciiDocMarkdown の方式に幅広く対応出来ることになり,当初想定よりずっと洗練されたものになった。

見出しの扱いは簡単なようで意外に複雑で,デルン初期実装では早期に実装していたものの,デライトに合わせた再実装がなかなか難しかった。出来てみれば,時間をかけただけのことはある。

昔の輪郭には見出しを使ったものも少なくないため,これらの可読性向上し,SEO にも寄与してくれることが期待出来る。

仕様

見出し記号には,当初予定していた星号に加え,要望による等号,実装途中で条件付きで取り入れられることに気付いた番号記号採用した。半角全角区別は無い。

実装しながら,最初の見出し記号の数も任意にした方が都合が良いことに気付き,最初の見出し記号の数を基準とすることにした。最初の見出し記号の数を下回る見出し記号が現れた場合は,それを新たな基準にする。

いずれにせよ,HTML見出し階層を飛ばすのは良くないとされているため,こうせざるをえないのだが,中景輪符の捉え方で,見出し記号2つで始めた方が直感的と感じる人もいるだろう。この仕様利用して,見送るつもりだった番号記号採用出来た。

読み込み中...
{進捗記録}{知番}{知名}{進捗}{拡張子}{404 Not Found}{希哲15年5月13日の開発}{輪郭の正規 URL}{希哲15年5月13日の進捗時限}{希哲15年5月13日}(21)
{開発}{曖昧}{一日一文}{悪い意味}{デライトについてのメモ}{デライト}{デライト市場戦略}{デライトの背景にある思想}{論組}{希哲15年5月の一日一文}(93)

{デライトはなぜ“抽象的”なのか K#F85E/E74C-AECA}

デライトに触れた多くの人が,デライトは“抽象的”だと言う。それもそのはず,我々認知しうる物事関連性徹底的抽象化することにより,あらゆる物事の関連性を一つの原理で捉えられるようにしたのがデライトの基礎にある「輪郭法」なのだから。

日常的会話の中で「抽象的」と言うと,捉え所が無いとか曖昧といった悪い意味に受け止められることが多い。しかし,抽象化という能力は,数学はもちろん,情報工学世界でも無くてはならないものだ。

工学における抽象性は,「汎用性」に近い意味を持っている。個別のものに共通する性質を取り出し,それらを一つの仕組みで捉えられるようにする。これが上手く出来ないと,論組プログラミングすら難しい

……などと御託を並べても,実際問題,デライトを多くの人に使ってもらうには,この抽象性が大きな壁であることに変わりはない。抽象的に物事を捉える能力には個人差が大きく,それも得意だという人の方が珍しい。当然ながら,これは市場戦略上の課題になる。

これを上手く解決する方法があるのか,実は開発者の中でも答えは出ていない。探せばあるのかもしれないし,結局無いのかもしれない。無いとしても,この抽象性がデライトにとって必要なものなら,無理にでも壁を乗り越えるしかない。


デライトは,これまで勘報機コンピューターでも多く利用されてきた単純な階層構造ネットワーク構造限界を越えるべく開発されたものだ。

特に「フォルダ」などとして広く使われている階層構造は,抽象性反対具体性具象性)と非常に相性が良い。いくら欠点があっても,人類が階層構造から離れられなかった大きな理由だ。

個人機(PC)の普及に大きく寄与したのが「デスクトップ メタファー」であったように,具体的モノ同士の関係として表現した方が多くの人は理解しやすい。その一方で,具体的なモノにはモノゆえの限界がある。

我々は,頭の中で多くの概念を縦横無尽に結び付けている。A にも B にも含まれている C という概念を頭の中では当たり前に扱えるが,フォルダのような物理的入れ物 A と B に同時に入っている C というファイル想像することは難しい。

こうした限界を越えようと様々な技術が開発されてきたが,フォルダのような“具体的”表現に頼っている限り,どうしても不自然で気持ちの悪いものになってしまう。「パソコン音痴」な人は,Windowsショートカットですら実体と区別出来ず混乱してしまうことがある。

それならいっそのこと,こうしたメタファーを廃してしまった方がいいのではないか。デライトの設計はそんな考えに基いている。だから,モノに喩えるのではなく,頭の中を直接表現した抽象画のようになっている。これをデスクトップならぬ「マインドトップ(mindtop,念頭と表現したこともある。

下図のように,デライトにおける「輪郭」は,視点によって一つの中身を共有出来る入れ物になっている。立体階層構造とでもいうべきこの構造を「輪郭構造」と呼ぶ。

この輪郭構造が,階層構造とネットワーク構造を{統合 K#F85E/A-3DCF}し,真に人間の{認知機能 K#F85E/A-E74C-CB77}に{調和 K#F85E/A-D4CF}するものになっている。大分長くなってしまったので,これについては後日改めて{解説 K#F85E/A-1EE6}しよう。
{進捗記録}{描写}{進捗}{希哲15年3月24日の開発}{自他輪郭}{希哲15年3月24日の進捗時限}{希哲15年3月24日の進捗}{希哲15年3月24日}{描き方ボタン}{描き方}(25)

{希哲15年3月24日10歩 K#F85E/E74C-F1FC}

描き方ボタン調整で終了。

いざ試してみると,輪郭一覧では思いのほか邪魔に感じる。一応描写が空の場合には非表示にしたが,それでも描き方を見たいような輪郭は割合としてそう多くないので,ほとんど無用の長物になってしまう。

自他輪郭も見分けにくい。描き直しボタン無意識にも自他輪郭区別に使っていたことが分かる。

考えてみれば,描き方を見て欲しい場合は特定輪郭注目させたい場合でもあるので,吊るし輪郭のみで十分だったことに気付いた。早速修正した。

{進捗記録}{}{描写}{進捗}{描写部}{選り手}{希哲15年3月10日の開発}{閲覧模動}{編集模動}{実用上の問題}(40)

{希哲15年3月10日11歩 K#F85E/E74C-C3D3}

描出フォーム仕様について検討

現状,知名欄描写欄が離れている描出フォーム装体について,両方開いている場合は合体させることにした。

美観上の問題も感じており,この自体は当初からあったが,もともと両欄は個別に開けるようにしていたため,挙動との整合性などを考えると難しい問題だった。

個別に開ける仕様自体は,閲覧模動編集模動区別明確にしつつ,出来るだけ操作感WYSIWYG に近付けたいという考えから編み出したもので,作業対象が絞り込みやすいこともあり維持したい。

少しずつ実装が変わり,最近では両欄が開いている時は一つの選り手とみなすようになっているため,合体させても違和感がなく,中止ボタン導入などを考えるとむしろ合体していた方が直感に適う。

これに関連して,中景部中景輪符描写部以外の部分を [Ctrl] + ダブルクリックして両欄を開くようにすることにした。これ以前から最近考えていたことだが,丁度良い。

現状,同操作は中景輪符描写部に対してのみ有効で,中景部の他の部分では反応しなかった。これは直感に反する挙動でもあり,描写部が空の場合の代置語を削除した最近の実装では同操作で描写欄が開けないといった実用上の問題もあった。

{希哲館訳語}{出番}{語彙研究}{立体階層構造}{平面的}{ウィキ}{情報}{階層構造}{問題}{デライト}(16)
{区別}

{}