I'd like to ensure that **all** content nodes are being stored in my
derived-output dirstruc. I see that (most of) the @ <file> types enforce
"no orphans" in subtrees, but I'm looking for notification on any "lost
orphans" that I neglected to place under the "supervision" of an @ <file>
caretaker. Of course the simple answer is "just be careful to make sure. .
.", but I'm looking for a way to automate this, without having to actually
parse the .leo XML data itself.
Any suggestions?
And while I'm at it, I'm also seeking more general advice, confirmation I'm
on the right track in getting to know Leo - feel free to skip the below if
my verbosity annoys.
I'm trying to establish a SOP for bringing pre-existing plaintext files
into Leo, in this case from external sources where the original file
contents must remain exactly as they are. Any and all comments welcome,but
especially if you see something I'm doing wrong.
- Keep external source file in the source-native VCS
- Import with @edit
- Change to @shadow
- Start extracting to "chunks" via section item nodes, creating a
"canonical tree"
- Keep both the original file and the Leo derived-output open in a diff
tool, regularly checking the latter matches the former
- Create "custom trees" - topic-based, function-based, audience-based etc
- Further split the content into sub-sections to an appropriate level of
"granularity" to suit intended later re-use
- Ensure that every content node is cloned into appropriate locations in
the custom trees
- Once initial-pass extraction is complete, "archive" the canonical tree
off where it won't need to be touched,
- - unless further, finer-level chunking is needed later, in which
case go back to using the diff tool to ensure original is preserved
- Start to add more "organizing" and "view" nodes, as well as custom
content to the custom trees
- Start inserting @shadow "roll-up" nodes, creating new custom files in a
completely separate dirstruc tree from the original source filesystem
- Put those dirstrucs into own authoring VCS, separate repo from the
external source-native one;
- - consider putting Leo file in VCS for continuous
snapshotting/rollback as well.
If this is a software project's source-code, complete this process with the
documentation first, then depending on the language used and my
ability/interest, perhaps also start doing the same with the program code
itself, inserting clones of snippets into the custom documentation trees,
in effect reverse-engineering the source dirstruc into a Leo-based
"literate programming" fork.
Even if I'm unable to contribute to the code itself, I should then be in a
good position to be able to contribute enhancements to the project's
documentation. Leo enables me to output completely customized "packages" of
the source project's own content, keeping it in sync with future updates by
continuing to update/pull into the "canonical" tree, checking for changes
needed to my self-authored nodes as I go along.
OK, sorry this was so long and if you've actually read this far thank you.
As I said any and all feedback welcome, but I particularly would like a
heads-ups on possible problems from more Leo-knowledgeable people on the
implementation details, before I get too much further along in my current
project. Seems like a good way to get to know Leo, as well as perhaps
taking baby steps down the road toward becoming a "real coder" one day 8-)
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/leo-editor/-/_Meb7D8q21MJ.
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.
