On Fri, Feb 27, 2009 at 8:57 AM, Ville M. Vainio <[email protected]> wrote:
> > In a limited sense, if we assumed program source (as imported with > @auto) as target of restructuring, we could encode the structure by > using *hash value of function definition line * (plus thin file name, > as possibly class name in python files) as gnx. > > That way, we could have our own structure in the .leo file and our > private files, and create clones to the nodes, while still being able > to grab updates from others (even updates that changed the function > order). Such a scheme is fraught with difficulties. Imo, experience has shown that reading external files must be extremely simple, otherwise data corruption or terminal confusion is almost inevitable. @auto is relatively simple because it does a full reparse every time. @shadow is relatively simple because it is based on easy-to-handle diffs. @thin is relatively simple because it uses sentinels. Furthermore, adding a tenth file type, even if it could be done, will not make Leo simpler or easier for newbies to understand. > > In any case, I don't think we can abandon @thin nodes. I agree. The essence of the situation is very simple: in a collaborative environment the external file must determine structure **all by itself**. We have only two robust options: parse the file (@auto) or put the structure in sentinels (@thin). Synchronizing information from multiple sources will never work. In a non-collaborative environment @shadow works great. Edward --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
