Since Leo files are so flexible, they can be considered as many things, I towards seeing them as collections of data. A node is a key:value pair, headline and body. A subtree is a graph of key value pairs, a Leo file is a graph of graphs, usually on a topic.
key: value examples: Classname: code graph Methodname: method code @auto: disk file @command: leo script FAQ: answer to the question ... I currently have over 80 Leo files on my hard drive: Lets call it surfeit of curiosity instead of deficit of attention. I would be interested in a store of all the nodes in all the files, allowing me unified access to their contents. I have put lots of notes, hints, reminders etc. in Leo I'd like to be able to marshal my thoughts on a topic, across the span of those Leo files. I'd like to identify duplication and popularity. I currently have _many_ places to stash points of interest, reminders, tips, facts, answers, ideas, etc. I would like to consolidate to Leo, but that means breaking out of the file-wise restriction. It requires a 'base' or 'store' for the data. The file-wise aspect is great for authoring the data, but doesn't work for analysis and retrieval, that's what databases are for. Thanks, Kent On Sat, Mar 30, 2013 at 4:56 PM, Edward K. Ream <[email protected]> wrote: > We've gotten a bit far afield with recent discussions of DB's. I'm > responsible for the digression. > > Obviously DB's are useful, but for whatever reasons, I just am not > interested in them. Consider it a failing of mine, if you like. Having said > that, I wouldn't mind Kent or Terry showing me how they are beautiful. > That's probably a conversation best left for happy hour :-) > > So let's refocus on the future of Leo. What problems with Leo (or .leo > files) would DB's be likely to solve? This would be a good topic to discuss > at the sprint. Your comments, please. > > Edward > > P. S. I would answer this question as follows. Imo, the biggest problem > with both Leo and .leo files is that the rest of the world isn't attuned to > the Leo way. What can we do, here and now, to ameliorate that situation, > without waiting for others to "get" Leo? > > For example, bzr understands neither .leo files nor Leo sentinels in > external files. As I use Leo, bzr commits don't always involve .leo files, > but they almost always do involve external files. So it seems to me that a > useful tool would be to represent a bzr diff as (yet another) Leo outline. > Leo's present conflict nodes are an example of this idea, as is Leo's > compare-outlines command. Generating outline-oriented diffs is actually a > *very* easy problem, because gnx's allow fast and foolproof determination of > which nodes have been inserted, deleted and changed. It is then trivial to > use difflib to report diffs in changed nodes. > > EKR > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/leo-editor?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
