Hatena::Groupdpmintkeyword

ツリーが目次でしかないアウトライナー

ツリーが目次でしかないアウトライナー

全体がひと続きのドキュメントで、ツリービューが目次でしかない方式のアウトライナーでは、ドキュメントから目次を生成する必要がある。

逆の生成順…ツリーからノードを複数選択して、それらを統合して1つのドキュメントに。ドキュメントを編集すればツリーの方に反映。ツリーを編集すればドキュメントに反映。…というのは困難。

ツリーからドキュメントを生成したのなら、逆方向(ドキュメントの変更をツリーに反映させる)の反映が難しい。

やるならドキュメントからツリー生成。つまり目次の生成。ドキュメントは1つで一括読み込み。



ツリーと編集欄の対応付け

ノードごとに分割読み込みするには、ノードとマージされたドキュメントとの対応付けをしなければならない。

対応付けをTextPointerや文字単位位置で行なうと、ユーザーによる編集でカーソル以降の対応付けがずれてしまう。ドキュメント先頭からの距離で対応付けているため。

対応付けをマーカーで行なうと、ユーザー操作によってマーカーが消えてしまう。それを回避しようとするとユーザー操作に制限をかけなければならない。

どちらにせよ編集欄を操作されるたびに、ドキュメントと関係のあるツリーをすべて再生成しなければならない。



編集欄もツリーなら可能

編集欄がツリーで、ノードが維持されるなら可。でもこれだとテキスト編集とは操作方法が違ってしまって利点がない。

目次部分はツリーを絞り込むだけのもの。つまりホイスト。



ツリーを複数選択しなければ問題なし

ツリー選択を1つだけに制限したり、(Shift+カーソルキーの)連続した範囲選択だけにすれば連結と分割の問題は起きない。

(Ctrl+スペースキーで選択するような)離れたノードを複数選択可能にすると統合と分割で問題になる。

ノードを選択することはホイスト(フォーカス)するようなもの。そのノード以下だけを表示。編集対象とする。



編集欄での変更をツリーに反映させる

編集時(TextChangedイベント)で、どのDOM要素が追加/削除/変更されたか分かれば、編集欄での変更をツリーに反映することが可能。編集欄のドキュメントがひと続きでなくても、ツリーから生成されたドキュメントであっても可能。

見出し文をハッシュ値にして、DOM内の見出し要素とツリー内ノードを対応付けておく必要がある。

TextChangedで変更されたDOM要素を検出したい



エクスポートすると長文になる

ノードは単一行、リーフはエクスポート時に前のリーフ(兄)とつながって1行になる。

親は見出し。下位を持つノードはすべて見出し化する。

これで単一行ノードだけで長い段落を書ける。情報操作方法が一貫されていい。

  • 空行(空ノード)で段落区切り。
  • 行頭に「・」でリスト

(ノード内で記法を使うということ)

下位を持つノードには見出し記法が自動的に追加される。下位を持たなくても(見出し記法を書けば)見出しにすることが可能。



:t/App