[Vimoutliner] graphs/trees

[Steve Litt]

On Monday 23 October 2006 03:05 pm, Scott Scriven wrote:
> * Peter Princz <princzp at gmail.com> wrote:
> > See them here:
> > http://princzp.googlepages.com/vimoutliner
>
> So, under the "limits" section, you mention wanting to represent
> graphs instead of strict trees.
>
> That's something I've given a lot of thought to over the past 5-6
> years, and I'm about to start work on a fifth prototype
> filesystem designed for this kind of thing.
>
> Basically, I've been looking for a filesystem which represents a
> directed graph instead of a tree.  So, it's still hierarchic, but
> instead of each node having one parent and multiple children, it
> would be multiple parents and multiple children.  It's like
> hierarchic labels or tags, built into the filesystem.
>
> If reiserfs4 allowed this, I'd have a good basis for building
> apps.  But POSIX forbids multiple hardlinks to directories, and
> has no decent way to "ls" parents, so I'm stuck using more custom
> storage to represent the graph.
>
> While it's a really neat idea and I'm interested in building it,
> I don't see this sort of thing being feasible in VO.  Since it's
> primarily a text editor, using plaintext storage, it seems
> like graphs would be very difficult and kludgy to implement.
>
> OTOH, VO almost makes me want to write v2 of my old outliner
> program.  VO has incredible text-editing capabilities, but it's
> fairly weak on the actual tree manipulation.  It would be nice to
> have something more like a hierarchic database, where each node
> can have its own unique set of attributes.  But I don't know how
> much I would actually use something like that, so I doubt I'll
> write it.  VO is arguably more useful most of the time, even if
> it is just a folding text editor with some macros and export
> plugins.

Hi Scott,

A guy named Gabriel Horner, who used to be on this list (maybe still is, but 
hasn't posted for awhile), came to my house one day and demonstrated a DBMS 
hosted version of VO. It wasn't very complete, but all the things that VO 
just can't do well because of its basic single parent hierarchy assumption, 
could be done quite easily in a database.

One could make an argument that a DBMS (mysql?) based VO backend would be 
every bit as efficient as the current one, if:

1) All keystrokes were the same (I personally think the keystrokes are what 
make VO so darned quick)

2) Outlines can be easily and quickly exported to tab indented format (in 
other words, the current native format)

3) All features are included (body text, interoutline linking, executable 
lines, checkboxes, hoisting)

Imagine how nice it would be to have each headline have a boolean datafield 
called "in-use". Think that might make hoisting a little easier? With a DBMS 
backend, clone headlines become a nobrainer.

Of course, someone would need to write a front end that implements VO 
keystrokes and look and feel...

SteveT