> My question - once I've emptied and deleted these two current .leo files
> and am managing the content externally, is there a recommended way to use
> Leo (presumably with activepath) so that I can automate bringing the whole
> dirstruc tree in so that it's all "read-only" AFA Leo is concerned? I then
> want to be able to refactor externally - rename folders and files,
> add/delete move directory branches around in the filesystem, maybe not open
> Leo for weeks, and then when I do, everything is updated and brought in
> sync.
>
> If I have to manually maintain stuff in Leo to match my often-changing tree
> with hundreds of files, I'll probably wait until things settle down and see
> how Zim goes first. . .
Of the top of my head response - I think there's a setting for
active_path that lets you specify which kind of @<file> node is used
for importing files. It's possibly, if my import approach was quick
and dirty enough :-) that you could get away with setting that to
"@view", and you'll just get the file contents loaded into a node which
will never write anything (because @view isn't a real @<file> type).
For updating, as long as you're sure there's nothing in the tree you
want, you can just delete the whole thing and have active_path load it
again. When you do an update it marks nodes for files which are no
longer present with asterisks, that might be useful for checking for
things in Leo not present on the filesystem.
Cheers -Terry
>> is there a recommended way to use Leo (presumably with activepath) so that I can automate bringing the whole dirstruc tree in so that it's all "read-only" AFA Leo is concerned? I then want to be able to refactor externally - rename folders and files, add/delete move directory branches around in the filesystem, maybe not open Leo for weeks, and then when I do, everything is updated and brought in in sync.
Of the top of my head response - I think there's a setting for active_path that lets you specify which kind of @<file> node is used
for importing files. It's possibly, if my import approach was quick and dirty enough :-) that you could get away with setting that to
"@view", and you'll just get the file contents loaded into a node which will never write anything (because @view isn't a real @<file> type).
> > for importing files. It's possibly, if my import approach was quick and
> > dirty enough :-) that you could get away with setting that to
> > "@view", and you'll just get the file contents loaded into a node which
> > will never write anything (because @view isn't a real @<file> type).
> >
> That's very helpful thanks, I hadn't caught that directive.
Um, I didn't know it was a directive - I just made it up :-)
I can't remember how active_path does its importing - I was hoping it
was simplistic enough to just create a node '@<xxx> filename.py' and
stick the contents of the file in the body - where <xxx> is whatever
you put in the setting for preferred @<file> type.
Now I think more about it I guess it does proper @auto / @shadow
importing, so maybe that won't work (even with a truly non-existent
directive, like @peek or @list or whatever :-)
Just too busy right now to actually look at the code.
Cheers -Terry
Um, I didn't know it was a directive - I just made it up :-)
I can't remember how active_path does its importing - I was hoping it was simplistic enough to just create a node '@<xxx> filename.py' and
stick the contents of the file in the body - where <xxx> is whatever you put in the setting for preferred @<file> type.
> And I assume you mean "activepath will create a node "
Yep.
Cheers -Terry