On Thu, Dec 18, 2008 at 2:48 PM, Ville M. Vainio <[email protected]> wrote: > > On Wed, Dec 17, 2008 at 9:26 PM, Kent Tenney <[email protected]> wrote: > >> Would it be feasible/interesting for Leo have a directive which referenced >> nodes/trees in other Leo files? >> >> Maybe clones, maybe some kind of `include` thing. > > Interesting thought, gnx's are sort of unique so you could quite > naturally have clones across leo files. However, read below... > >> My guess this wouldn't be worth pursuing unless Leo had a >> node database back end, in which case it would be automatic, since any >> Leo file would effectively manage an arrangement of nodes from the db. >> >> Would it be hard to put the content of nodes into, say, an sqlite db? > > Hey, that sounds familiar ;-).
hehe, evidently I'm a parrot. > > My thought has been that the sqlite db should be used as the gnx store > (tnodes), while the outline would still be like in the current xml > files. Of course the xml could still be stored normally in a blob in > the sqlite database. > > The implementation of this would be simple, esp.when every leo > document would have a separate sqlite db. However, shared database > seems like a version control nightmare (what happens when you do bzr > pull and re-import the leo file? Do all of the instances of that tnode > change, even in "old copies" of the document?). > > Here's an idea how it would be feasible from ui and implementation > perspective: finally implement that "lazy node" thing. Make all the > lazy nodes global (i.e. stored in a shared tnode database in ~/.leo. > > When you do "make_subtree_lazy" command on a node, all subnodes > (tnodes) will become lazy (including clones). With that, you also > implicitly agree that you can't version control the nodes anymore > (i.e. you will always have the version you last imported in all the > .leo files that reference that node). The laziness will also be > specified in outline, so everybody that imports your leo file will > have the specified nodes as lazy (and shared). > > This would be rather simple, apart from cloning trees across outlines > (individal nodes would be cloned, but outline-manipulating operations > would not become visible in other leo documents). To do that, the > outline structure (of lazy nodes) would need to move to sqlite as > well. I don't think that is showstopper-hard either, but then you > would have to propagate signals about outline-editing to all the open > leo instances when you save (i.e. commit). Also, vnodes would need to > grow an identity. > > Er, hope that peace of incoherent rambling made at least some sense. I don't use clones, so I tend to underestimate their effects. The version control issue is certainly a problem. I guess the Leo files would only arrange IDs, the content would all be in the DB. I don't know what that would look like, 'nightmare' is probably a good description when the Leo file and the DB got out of sync. After that it goes over my head. The motivation behind the post is finding myself duplicating content in different Leo files, confusion about which is best and frustration over repeating myself. With programming languages this led to the `library` model of shared code. Referencing nodes in other Leo files might offer some advantages with less nightmare, again, sure to be trickier the harder one looks at it. > > -- > Ville M. Vainio > http://tinyurl.com/vainio > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
