Hi: I have a question or maybe a concern with this.
When you say "will write @file nodes exactly like @thin nodes" does that mean that the source for the external file will no longer be kept in the .leo file? If so, I think that will break my current usage / work-flow. Right now I keep only the "foo.leo" file under version control, and delete all the derived files that make up my project periodically. So a clean instance of my project is just "foo.leo", then when I write the missing @file nodes, I get "f1.tex", "f2.py", "f3.tex" and so on -- all the individual files that are needed. So in this model, the ".tex", ".py" etc. files are simply intermediate files (like ".pyc" etc.) that are not essential to preserving my work. This suits my work-style, rather than having to keep all the files under version control. I use "@file" precisely because of this property. I guess i could use "@nosent" or something like that, but in that case I lose the ability to edit the external files externally, and have the changes revert back to the "leo" file. Clearly if you make this change, and @file goes away, my world does not end. However there is something attractive and satisfying to me of having all the small files of various types which make up a project bundled together in one source file (the ".leo" file) that I can then treat as a single entity for archiving, copying, backing-up etc. without worrying about keeping track of all the individual sub-files. Or am I missing what you imply by making @file work like @thin. Cheers, =John On Aug 25, 9:40 am, "Edward K. Ream" <[email protected]> wrote: > I am running into complications with the one-node world. This is no > great surprise. > > For starters, I have added a g.enableDB switch that turns off file > caching. That way I have some hope of debugging read code :-) I plan > to make this a command-line option. There probably should also be a > command to clear the cache, excepting perhaps the LEO_EDITOR key. > > Another complication is that the tnodeList hack that underlies @file > nodes. There has been some discussion of making @file work like @thin > in a **backward compatible** manner. That is, Leo will read "legacy" > @file nodes (and external files) as it has always done, but will write > @file nodes exactly like @thin nodes. > > Does anyone have a big problem with this plan? The only objection I > can foresee is that @thin sentinels are a bit more complex that @file > sentinels, but imo this is not a strong enough objection. �...@file is an > accident waiting to happen for shared repositories. > > Finally, I think pickleshare.py should be moved into Leo's core. It's > used by Leo's core and is an essential part of caching. At present, > it's pretty much hidden in the external directory, and furthermore, > leoExternal.leo should be folded into leoPy.leo. > > Comments please. > > 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 -~----------~----~----~----~------~----~------~--~---
