On Fri, Jul 4, 2014 at 7:32 AM, Kent Tenney <[email protected]> wrote: > the problem with UNLs is they don't allow choices which involve > changing the headline. If I change the name of a method, I don't > want to lose the choices for the implementation of that method.
Yes. It's a big problem. > Thanks for doing the work re: gnx setting. The code you provided > works a champ. Glad to hear it. > The idea would be a table in the companion db which, on closing > the Leo file would generate key/value pairs @auto tree UNL / gnx > on opening the Leo file and after parsing the @auto file, the > @auto tree gnx's would be reverted to the previous ones, simulating > the persistence of regular nodes. No collision issues. Interesting idea. Btw, is there a reason not to use c.db? It works just like a persistent python dictionary, so for prototyping it should work fine. > Come to think of it, the table in the companion db could also trivially > save the ua of the @auto tree nodes, ... at which point the @auto > tree nodes are as rich a data store as a regular node. I'm not sure I understand what exactly you are doing, but I sure do like the direction this is heading. > If the file had been edited outside Leo since Leo saw it last, the nodes > in the db could be tagged as obsolete, or new records created accordingly. > > If the db were updated on changes instead of on closing, less would be > lost in a crash. > > I'll ruminate this approach until the reason it won't work rears it's ugly. Keep up the great work! Edward -- 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. For more options, visit https://groups.google.com/d/optout.
