{察しが付く}{造語の難しさ}{新しい言葉}{伝わりにくそう}{Qt: 遅延評価勉強法}{遅延式勉強法}{意味すること}{伝わりにくい}{知っている}{想像以上}...=}(20)

{遅延評価勉強法 K#F85E/E74C-3D8F}

遅延評価」という概念知っているイメージしやすいような造語仕方だと思うぱっと見で,どのに向けたどんななのか察しが付く。「遅延式勉強法」は「遅延」が意味すること理解している前提なので伝わりにくそう。ただ,十分に意図理解しているにとって「遅延評価勉強法」が回りくどい表現なのも確か

新しい言葉って想像以上伝わりにくいので,普及させる段階ではぱっと見イメージ出来るかどうかは重要というか,「その言葉について5分以上考えてくれる人はまずいない」くらいに考えておいた方がいいのだろう。

=}
{新生デライト}{難しい質問}{超かんたん}{自由市場}{デライト(なんでもメモ)}{分からなかった}{デライト}{階層関係}{森羅万象}{あれ}...=}(55)

{引き入れについてのご質問から考えたこと K#F85E/E74C-C61D}

大変回答が遅くなってしまい申し訳ありません。色々なことを考えさせられるご質問で,デライトにとって非常に重要な宿題を頂いたように感じています。ありがとうございます。

だいぶ時間が経っているのでお考えが変わった部分もあるとは思いますが,他の方の参考にもなるように文章を残しておきます。まずは,ご質問の内容に沿って,出来るだけ端的に書けることを書いてみます。

引き入れについて

宇田川さんは、知名のみの輪郭をよく引き入れられ欄に引き入れているように見受けられます。

まず,「引き入れられ欄に引き入れる」という概念が私の中に無かったので,難しい質問でした。「引き入れる」というのは,ある輪郭の中に他の輪郭を文字通り「引き込むように入れる」,ただそれだけの極めて単純な操作で,それをする方にとっては「引き入れる」,される方にとっては「引き入れられる」ということになります。

例えば,フォルダの中にフォルダを入れる操作に相当します。ただ,多くのツールでは,データの内容とデータ同士の関連性は別々の画面に表示されます(別のウィンドウやサイドバーなど)。輪郭は,輪郭の内容と他の輪郭との関連性を一緒に表示させる仕組みを持っているのが特徴的です。これは,画面を切り替えたり視線を大きく移動することなく,内容と関連性を確認したり修正したり出来るようにする工夫です。

「輪郭をどの輪郭に引き入れたいか」というごく単純な考え方で使えるように設計したつもりでしたが,この見た目が「引き入れ欄に引き入れる」や「引き入れられ欄に引き入れる」という複雑な考え方をさせてしまっているのかもしれません。

このように、知名のみの輪郭を引き入れられ欄に輪括させるのは、主にどのような効果を狙ってのことなのか、ご教示いただけませんか。
あるいは、実際に効果があったと感じた出来事・体験をお伺いしてもよろしいでしょうか。

特に「知名のみの輪郭」という意識をしたこともありませんでした。その時に知名だけで十分なら知名だけの輪郭が出来ますし,当然その後描写に書き加えることもあります。知名があるか描写があるかということに固定的な意味はありません。私にとっては,この「知名のみの輪郭」という意味ありげな概念もどこから生じたのか不思議でした。

t_w さんも書いているように,アウトライナー項目をざっと書き出していく感覚に近いかもしれません。ある項目をある項目の下位に移動させることも引き入れに似ています。

平面的なアウトライナーに対して,各項目が独立していて,どの角度からでも階層関係立体階層構造を作ることが出来る。これがデライトを「立体アウトライナー」と呼ぶ理由です。大袈裟な言い方をすれば,私はこれを使って「(普通のアウトライナーでは不可能な)森羅万象アウトラインを書き出している」ところです。その単位をそのまま「輪郭アウトライン」と呼んでいます。

アウトライナーで最初にざっと書き出してみた項目も,ご質問にある「知名のみの輪郭」も,言ってみれば「情報の」です。どのようにでも成長していく可能性があり,何がどのように役立つかは予め分かりません。ひたすら蒔いてみるしかないわけです。


効果」というのも正直困った部分でした。私は息をするようにデライトを使っていて,その恩恵に依存して生きているようなところがあるので,「空気に効果があったと感じた出来事」を聞かれているような感覚でしょうか。

ある言葉に関連する言葉がこういう形で連なっていれば,日々気付かされることは枚挙に暇がありません。思い出せなかったことを思い出すこと,気付いていなかった概念同士のつながりを発見すること……これ自体はデライトのごく基本的な使い方です。

全知検索について

当方が同じ操作を行う場合、短期的には全知検索の検索語として、未来の自分が検索することを見込んでいます。

しかしながら、ただ検索に引っ掛かるためだけに輪郭を増やしていくと、描写のない輪郭が増え、デライトの持つ「同じ知名の輪郭を複数作れる」機能の恩恵を受けられず、形だけの輪括だけが増えていってしまうように感じてしまいます。

これも理解の難しい部分でした。「同じ知名の輪郭を複数作れる機能の恩恵」,「形だけの輪括」が何を指しているのか分かりませんでした。「描写のない輪郭が増えることで何らかの恩恵が受けられない」と感じたこともありませんでした。

そもそも,「同じ知名の輪郭を複数作れる機能の恩恵」というのは,「絶対的な名前のない情報を扱えること」以上でも以下でもない,極めて単純自然なことだと思っています。例えば,ツイートのような思いのまとまりにいちいち名前を付けていられませんし,同じ文字列で表現されていても異なる物事がたくさんあるのが我々が住んでいるありのままの世界です。ウィキなどでは全ての物事に固有の名前を付けるという極めて不自然なことをしてきたわけです。それを排し,文字通り「なんでも」記述対象に出来るようにしたのがデライトです。

「検索に引っ掛かるためだけに輪郭を増やしていく」という表現から,どうも全知検索の趣旨が上手く伝わっていないらしいということは分かりました。全知検索というのは,「検索に引っ掛かるように輪郭を増やしていく」こととデライトに知識を蓄積していくことを同一視し,それを促進するための仕組みなのです。

引き入れによってある輪郭からある輪郭への関係が作られるということは,脳内にある情報が輪郭として表現され,それがつながっていくということです。これは頭脳をデータとして再現するということであって,デライトが実現したいことそのものです。それはそのまま検索結果を充実させることにもなるわけです。

たまに「検索用の輪郭」という表現が使われることがありますが,「検索用の輪郭」「検索用ではない輪郭」という分類も全く本質的ではありません。それが有用な分類であればそういう機能にしています。デライトではそれをあえて排しているわけですが,この意図もあまり上手く伝えることが出来ていません。頭の中にある情報は全てが他の情報を引き出す鍵でもあり,その意味では全て検索用です。それをそのままデライト上で表現して欲しいというのが全知検索の趣旨です。

私はデライトを使って自分の頭の中にある全ての物事を紐付ける作業を日々しています。それによって,頭の中で情報を引き出すようにあらゆる情報を自由自在に引き出すことが出来ています。これ以上「恩恵」のあるメモツールを私は知りません。

考え過ぎないこと

どうせ輪括するのであれば、もっと長期的な効果を見込みたく(そこそこの信念を持って輪括したく)、輪郭法を長年使い込んでいる先輩のご意見を頂戴できればと思います。

一つ助言するとすれば,個人知識管理においては「書く前に考え過ぎること」が最大の障害です。

デライトはその障害を最大限排するように設計されています。例えば,名前を付けなくても体裁を考えなくてもまずは書き出してみて,後からいくらでも修正出来るように作られています。こういった点においてデライト以上のものはなかなか無いと思います。

引き入れについても同じで,そこまで思い悩んで使うものとして作っていないのですが,実際にはあれこれ考えさせてしまうことが多いです。これは明確に伝え方の失敗であり,日々反省しているところです。

計画し過ぎないこと

「知名のみの輪郭」「検索用の輪郭」「形だけの輪括」……こうした利用者によって再発明されがちな区別を排して輪郭という単位であらゆる情報を平等化している理由は,情報が持つ役割を決めつけず,「設計」よる破綻を防ぐためです。

近年,Notion のように情報を自由に設計出来るツールが人気を集めています。それもそのはずで,誰でも最初は自分が思い描いたように設計出来ると嬉しいものです。絵に描いた餅を見ているわけですから。ただ,その大半がまず間違いなく失敗していきます。これは Notion どうこうではなく,人間の計画性というのはそんなものだからです。

個人知識管理の実践を重ねていくと,計画というものがいかに破綻しやすいかということを学びます。したがって,経験豊富な人ほど計画に依存しない方法を求めるようになります。これは,差別がなく自由市場のある社会の方が発展しやすいことにも似ています。人と同じで,情報も成り行き任せに育てていった方が強くなります。デライトは,どのツールよりもそこに最適化されたサービスです。

デライトは簡単です

デライトは,その必要性分からなかった人にとっては「意味不明な用語が多くて分かりにくいサービス」だと思います。見慣れない UI や用語に慣れようという動機が無いからです。

一方で,本当に使いたいと思っている人にとっては実は簡単過ぎるくらいのサービスです。用語といっても小学生でも分かるくらいの表現しか使っていませんし,量も他製品に比べて特に多いとは言えません。登録するのも使うのも実際には「超かんたん」です。というのも,デライトは誰でも使えるようなサービスとして設計され,誰でも理解出来るように努めてきたからです。

ただ,この徹底した「簡単さ」が,デライトの高度な部分に惹かれてきた人ととの間にすれ違いを生んでいるのではないか,という気がしています。小学生でも分かる 1+1 について考え込んでしまう大人がいることに似ているかもしれません。デライトは難しいもの,という先入観があると,簡単さにも構えてしまいます。

デライトは簡単に使えるように作られていますし,簡単に使えるものです。

感謝

cat さんは,数少ない初期デライトの重要な貢献者です。

その方から頂いたこの質問を読んだ時,最初から最後まで意味が分からなかったことに頭を抱えました。自分は一体どれだけ利用者について理解していなかったのか,という感じです。それから毎日,開発者と利用者の間にあるについて考えてきました。回答にここまでの時間を要した理由です。

それと同時に,デライトの大きな課題を解決するヒントがここに隠されているのではないか,という気がしています。これも,率直な勇気ある質問がなければ気付けなかったことなので,本当にありがたいことだと思います。

いまデライトは,「新生デライト」に向けて文書整備を一気に進めようとしているところです。cat さんに限らず,皆様には,ふだん疑問に感じていることがあれば遠慮なく投げかけて頂きたいです。どんな疑問であれ,それと向き合うことがデライトの財産になります。

{希哲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年2月23日の開発}{希哲16年2月23日の進捗}{利用すべき}{過ぎなかった}{可能にした}{続いていた}{具体性に欠ける}{外部言語の埋め込み}...=}(56)

{希哲16年2月23日6歩 K#F85E/E74C-365A}

進捗時限記録中略

埋め込み記法渡括記法に関する昨日の検討続き終了

これまで「埋め込み記法」は渡括記法一般向け名称としていたが,渡括記法上位概念とすることにした。

外部言語の埋め込み」を担う交度埋め込み記法考案によって,これまでの渡括,すなわち「外部利素の埋め込み」に留まらない役割持つようになったことが決定的だった。


概念として多くの人にはまず伝わらない渡括トランスクルージョン代わりに埋め込み」という表現使うようになったが,これはこれで具体性に欠ける表現なので,結局渡括記法埋め込み記法)」のように併記せざるをえないという状況続いていた

妥協過ぎなかった埋め込み」という概念曖昧さ抽象性交度埋め込み記法のような応用可能にしたとも言えるので,むしろ積極的にこの抽象性利用すべきではないかと考えるようになった。+ もどちらかといえば埋め込み一般使うのが相応しい記号だ。

これで一般向けにも分かりやすい埋め込み記法」を堂々と使えるようになり,すっきりした

=}
{HTML}{駒手記法}{進捗記録}{あれ}{希哲16年2月20日13歩}{神秘的な}{別に}{実装した}{付けた}{階層区切り}...=}(248)

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

進捗時限記録中略

不意に閃いた階層区切り線」についての方針まとめて終了

従来の見出し未満区切り線記法に,見出し階層越えられる階層区切り線」を加える。以下のように,唯一通常の区切り線区別出来る見出し記号 #全角 使う

* 第1階層
** 第2階層

#========================#

第1階層段落。

#------------------------#

第2階層段落。

#- - - - - - - - - - - - #

第3階層段落。

#. . . . . . . . . . . . #

第4階層段落。

##

第1階層段落(# の数でも調整出来る)。

持ち辺モチベーション

従来の区切り線記法は,HTML において対応する <hr>性質上見出し未満区切りにしか使えなかった

見出し階層作った後で描写全体に対するフッター的なものを書こうとする第1階層見出し作る必要があるが,しばしば大袈裟感じられることがある。

検討過程

空見出し」の挫折

今回検討当初は,「空見出し」という概念主に考えていた区切り線長さ任意であるべきなので,どうっても自然な形階層調整出来そうになかった。その点,見出し内容出来れば手っ取り早い

しかし,等号星号区切り線使う予定なので,== のように第2階層以降で内容空にする衝突することになる。

区切り線の方を見直しても,--区切り線なら == はやはり二重区切り線であってほしい。直感性下線形見出しとの整合性考えるとこれは捨て難い星号による区切り線はそれに比べればまだ転用余地があったが,その代わり *使う Markdown の区切り線記法との互換性損われる

そもそも,「空見出し」という概念にも無理がある文字を書くから見出しなのだし,実質的に区切り線なのだから,直感的とは言い難い

階層区切り線」の閃き

ここで,唯一区切り線記法被らない見出し記号である番号記号思い出した

番号記号による見出しは,ハッシュタグ駒手記法との衝突避けつつ atx 式見出しある程度互換性持たせるため,## のように2個以上条件対応していた個人的に好きな記法ではなかったこともあり,おまけのような扱いで,ここまで気付かなかった

すでに「空見出し」に感じていて,区切り線記法での対応立ち返っていたことで,この ##特殊な区切り線みなせる特徴持っていることに気付いた記号2個以上繰り返す区切り線見える記法で,実際普文枠線的な装飾使われることが多い記号でもある。

特に,区切り線記法としての統一感直感性保てる2個第1階層表せるということは決定的に重要な点で,見出し記号個数階層関係一致しないとどうしてもちぐはぐ見えてしまう。これは,衝突回避したとしても等号星号では解決出来ない問題だ。区切り線記号としての最短形見出し記号としての第1階層対応しうる唯一記号番号記号だった。

ただし,通常の区切り線記号異なり,個数階層対応するため,普文装飾兼ねられないという問題があった。上位階層区切り線普文上で目立つように書けない

これは,最新の区切り線記法下線形見出し記法検討9日17歩19歩踏まえ見出し階層対応する4種区切り線組み合わせる解決することにした。つまり,第1階層から順に最短形#==##--##- -##. .# というように区切り線組み合わせることが出来るようにする。これがまた都合が良いことに,よくある装飾見える

9日15歩以後,見出し下線区切り線長さ区別出来るようになっているため,区切り線装体にはある程度多様性持たせ問題ない一方見出し下線階層表す装体になっているため,一定制限必要になる。この点でもぴったり噛み合った

別に2個以上良いだろうと実装した区切り線記法おまけ感覚付けた番号記号による見出し記法最近の拡張方針……何気ない全てパズル要素だったかのように思える神秘的な閃きだった。

番号記号見出し仕様厳密化

この階層区切り線考案に,番号記号による見出し常に2個最上位階層とすることにした。つまり,*=##始まる見出しはともに最上位階層表す

これまで異なる見出し記号併用することは特に想定しておらず,実際使われていないはずなので,記号個数単純に計算していた。見出し階層相対的な個数決まるため,*始まる見出しがあると ##第2階層になる。これは階層区切り線整合しない。

特に仕様として決めていたことではないため,ここで厳密化することにした。

実装上の課題

仕様完璧思えるが,実装上の課題残った

HTMLCSS機能的には,可接性ちつつ見出し要素隠すことは造作もないが,SEO 上の懸念多少ある。今の検索演心評価理積みはそこまで単純ではないだろうが,伝統的に見出し要素隠すべきではないとされてきただけに,どこまで不利になるか分からない出来るだけ行儀の良い実装方法見つけたい

そもそも見出し要素にしてはいけないのか,<section> あたりを使って上手く誤魔化せないか,など色々考えてみたが,どれも多かれ少なかれ怪しさ残る

見出しの無い階層区切りというのは HTML想定外だったのだろう。

{用者}{HTML}{HTML5}{デラング}{進捗記録}{高い}{あれ}{役割を持たせる}{役割を持つ}{緩衝的}...=}(248)

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

進捗時限記録中略

昨日寝る直前にまた脳爆発があり,今朝にかけて文字装飾記法タグ記法周りの概念整理仕様整理急速に進んだ

文字装飾記法は,「文字装飾を伴う慣用表現」のための記法位置付けることにした。太字記法##斜体記法//下線記法__打ち消し線記法~~翌日のまとめで「打ち消し記法」から改称4記法基本とし,それぞれ所定装体スタイルを伴う <b><i><u><s> HTML 要素対応する

@ を使った文字サイズ記法% を使った色記法検討していたが,タグ記法概念が出来たことで中途半端なものになるため,これは廃案とする。

文字装飾記法はこれがほぼ完成形か。

検討過程

3つ検討方針

実装自体は容易部類で,記法概ね固まっていたにもかかわらず文字装飾記法実装踏み切れなかった理由として意味論的な問題があり,これが思いのほか難題だった。実装方針3通り考えられる

  1. 完全に意味論的な記法にする
  2. 完全に装飾的な記法にする
  3. 意味論装飾重ね合わせた記法にする

記法趣旨からしても,軽量標記マークアップ言語特性を考えても,1つ目に無理があるのは明らかだ。対応する HTML<b><i><u><s> は,私が何度解説を読んでもややこし感じる代物だ。それを多くの人正しく理解して使うのは不可能だろう。そもそも「文字装飾記法」という分かりやすい説明体系捨てることになるが,代替案があるわけでもない。

かといって,2つ目ももったいない。要は <span>装体指定だけにするということだが,例えば,太字にはしたいが <b> にはしたくない場合打ち消し線引きたい<s> にはしたくない場合がどれだけあるのかと考えると,無難通り越して臆病過ぎる失う可接性アクセシビリティ応用可能性釣り合わない

最終的に採用することになった3つ目も,全く考えなかったわけではないが,柔軟性に欠け,前の2つの悪い所組み合わされる気もして,有力案にはなっていなかった。

タグ記法による書き分け

この膠着状態変えたのは,前日概念としてまとまったばかりのタグ記法だった。

これまで,デラングにおける HTML は,どうしてもデラング出来ない表現をしたい場合などの“抜け道”とか“救済措置”に近い位置付けで,積極的に使うことを想定していなかった。実際個人的にはほとんど使っておらず放置している不具合多い部分だった。

デラングタグ記法として間接的に HTML使うことで,略記法導入可能になり,HTML 側の仕様変更に対しても一定の緩衝帯設けることが出来る。ここに来て初めて文字装飾記法でも「書き分け」が考えられるようになった文字装飾記法対応しうるのが全て1文字要素だったことも幸いした

昨日寝る直前に,##太字的な表現##<{font-weight:bold}>太字</> のように書き分けるよりも,##太字##<b>太字的な表現</b> のように書き分ける方がマシであることに気付いて,1つ目の実装方針完全に潰せた

これにより一時的に2つ目の実装方針再浮上したが,標準的に使う記法として標準的な用途最適化不足なのはやはり否めなかった

決着

最終的に,「文字装飾を伴う慣用表現」という用者自然に理解出来る範囲での意味論的位置付け与え逸脱する用途ならタグ記法書き分けるのが使用頻度に対して最適だろうという結論に達した。3つ目の実装方針洗練させた格好になる。

例えば##太字## は「太字装体<b>」に対応する装体邪魔なら <b>太字的な表現</b>書けるし,意味邪魔なら <{font-weight:bold}>太字</>略記法検討段階のように書けるが,これらの場合稀少なのは明らかで,記述量上手く釣り合うワープロならともかく,軽量標記言語手書きしようという人にとって難しい使い分けではないだろう。

そもそも<b><i><u><s> は,古くからある視覚的要素HTML5慣用的な用途引き継いで意味論化されたものなので,「文字装飾を伴う慣用表現」と非常に相性が良い相互変換にも全く問題ない

何より,直感的に入力すれば構造的に出力されるというデラングの理想適っている

文字サイズ記法色記法廃案

文字装飾記法を「文字装飾を伴う慣用表現」と位置付けたことで,慣用表現を持たない文字サイズ記法色記法仲間外れになるが,タグ記法によって出る幕がなくなった感があるので,ここで廃案にすることとした。

第一に,タグ記法略記法整備した方が一貫性応用可能性高い特定プロパティ省略出来るようにし,<{white}>白い文字</> のように書ければ,%white%白い文字%% と書くのと記述量大差ない

もともとパラメーター必要とする記法異質感はあり,文字装飾記法統一感損うかという懸念はあったので丁度良かった

波及的検討

波及的に,いくつかこまごまとした検討進んだ

組み合わせは「」ではなく「入れ子」へ

これまで,複数文字装飾記法組み合わせ#/太字と斜体/# のように,「記号を1つずつ逆さにした終了記号挟む」といったややこしい説明考えていたが,##//太字と斜体//## のような「入れ子」を #/太字と斜体/#短縮出来るという考え方にした方が分かりやすいため改めることにした。

タグ記法発展

今回検討で,タグ記法早くも実践的な役割を持つことになり,デラングにおける存在感一気に増した

タグ記法HTML仕様変更対する緩衝的役割を持たせること,要素名省略<span> にすることを考え始めた

{概念}

{}