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.
