On Tue, Jul 8, 2014 at 10:14 AM, Edward K. Ream <[email protected]> wrote: > On Tue, Jul 8, 2014 at 8:18 AM, Kent Tenney <[email protected]> wrote: >> Wondering about current status and potential direction: >> >> There have been a couple of mentions of @auto nodes >> gaining persistence, what are the chances of this happening >> in core? > > If we can do it, it will find its way into the core. > > It seems to me that we are in time of creative ferment/confusion on > this topic. > > The recent discussion re clones and bookmarks and urls is one way it > might happen. Fidel's idea of tracking changes to nodes in a way (if I > understand him correctly) that might preserve unls might be another > way. And your work, Kent, with db's is part of the mix. > >> Something like persistent UAs, such that >> @auto <file.py> would store the UAs of the tree, putting >> them in it's UA. > > It's not the persistence of the uA's that is the problem:
The persistence problem would be solved if the UAs were persistent. They would contain the primary key of the node, whether it is a gnx or something else. When I began I took this approach: creating a 'str_pgnx' key in the UA: persistent gnx. Since the problem is with @auto, wherein the nodes are always re-created upon reading, gnx is not so canonical. If the @auto node's UA contained a UA for each of the last seen nodes, their connection to the db would be maintained between sessions. If the primary key attached to an @auto node was OTHER than the gnx, it would increase the potential for collaboration, since the 'user' component would not interfere. it's the > persistence of the identify (gnx's) of nodes or alternatively, the > persistence of node-related bookmarks. Persisting gnx is the platinum > standard; persisting bookmarks might be good enough. > >> I'll start on scaffolding outside Leo to persist @auto nodes >> if this isn't going to happen, but core would be nice. >> #cough#(someone else does the work)#cough# > > I think we are all, in various interestingly different ways, working > on this problem. You could say we are working in a slow-motion sprint > ;-) My guess is that eventually the confusion will clear, and a clear > way forward will appear. When that happens, the solution will move to > the core. > >> However, when working with source code, I consider the correct structure >> to be that provided by the language: declarations, functions, classes, >> methods ... exactly what @auto does, no more, no less. > > I disagree. You seem to be forgetting organizer nodes. An organizer node is what Leo uses to name a chunk, no? That's what I consider the correct degree of decomposition. > > 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. -- 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.
