RFC for outlining

[bburns]

I was wondering how one might go about writing an outline in subtext, or writing one with an editor that supported transclusions. You guys have probably already thought this through, but I've been wondering how I was gonna do it in Neomem also.

So, this is a bit pedantic, but it helped me understand the issue better.

This is a solved problem with things like Roam and Logseq, which both use lines as blocks, as I understand it, and have custom editors. I haven't tried Roam, and didn't stay long with Logseq.

Alternatives:

• Embedded outlines - could use indentation as in Python or Markdown. Space as a sigil character? This goes against the idea of a flat list of blocks. But it's lightweight, and simple for a text editor to work with.

• Transcluded items - each item could be a separate memo, and each parent embeds references to its children. This seems rigid though - like a strict folder hierarchy.

• Store link to parent in each child item. Also rigid.

• Graph of items - each item in the outline could be a separate memo, and links between them are stored in an edge table. This seems heavyweight for just a simple outline, but preserves the idea of a flat list of blocks. Different orderings are possible in the same db.

So if we want a set of notes that could be arranged in any linear order or hierarchy, storing them in a graph makes sense.

How would you transform a text outline like this to a graph version?

• home
  • ladder99
    a data pipeline
    • task1
    • task2
  • neomem
    a data gateway
    • task3
    • task4
      • task5
      • task6

Flatten everything - each item to a node - eg with addr:contents for shorthand -

home
ladder99: a data pipeline
task1
task2
neomem: a data gateway
task3
task4
task5
task6

and construct the edges between them - eg from, relation, to, props - which could accommodate ordered lists, trees, graphs, and have multiple hierarchies possible.

So say we have that list of nodes, and a list of edges like this -

home, parent, -null-, {}
ladder99, parent, home, {order:1}
task1, parent, ladder99, {order:1}
task2, parent, ladder99, {order:2}
neomem, parent, home, {order:2}
task3, parent, neomem, {order:1}
task4, parent, neomem, {order:2}
task5, parent, task4, {order:1}
task6, parent, task4, {order:2}

Now we've got a graph storing an ordered tree. If we need to rearrange things it's a matter of changing the numbers - floating point can go pretty far before needing to renumber a set of siblings.

You can define multiple trees/orderings on the same items, by using a different relation address, eg parent2, container, part-of, etc.

q. How would an editor render this?

It could traverse the graph structure, being wary of cycles. eg start at null - who are the children of null? home. who are the children of home? ladder99, neomem. It could do depth first traversal and add divs to a doc, with indentation. Use the order in the props set to order siblings.

q. How would an editor let you edit this tree/outline?

Say we have a rendering of the tree with each item having a text input for heading and a textarea for contents. Then changing the values is easy.
Can reorder things by shortcut keys or mouse and updating order values.
And can switch between different orderings by selecting the relation name/addr.
It's easy to show a flat list of all the items, or any number of trees, or graphs.

For Neomem I had gotten as far as a flat list of items connected to a db - catch the up/down arrows when you're at the start/end of the textarea to move to prev/next item. Hadn't thought through outlines/graphs yet.

I haven't read enough about Subconscious to know how this all connects with the rest of the system. For Neomem each item would have a uuid, but you guys have content-addressing in mind? With some kind of address/alias system?

I'm still trying to catch up!

Anyway, as far as Subtext goes, I guess this doesn't have much bearing on it, other than that transcluding items is one way to make an outline...

[bburns]

I guess storing a reference to a subitem would be fine - I was mixing up the text representation with how it's stored in the db/index, which is arbitrary - could be a graph, or a tree.