On Wednesday, November 30, 2011 10:35:07 PM UTC+7, Terry wrote:
>> so if fifteen years from now I'm not using Leo anymore, the next 50,000
chunks of text I've captured/written won't need a programmer to continue
being accessible, relatively easy to transform into whatever I'll be using
next.
>> My goal is to *not* make use of structures that are specific to Leo,
> Fundamentally Leo stores data in XML. It's always going to be possible
to get data back out of a .leo file without Leo, although it might require
tools / skills somewhat different from plain text. But storing a tree with
clones in plain text would make the plain text so sentinel heavy it might
as well be XML...
Yes, but the beauty of the @shadow structure is, "who cares"? The only
people that are going to look at the sentinels are programmers who care
about Leo. Therefore sentinels in @shadow files can carry all the important
data right out in the filesystem.
>> In the browsing/googling I've been doing since, maybe the idea of "UNL"
are a good approach? Whatever I do, I'll need to keep the link source
strings in sync with the target name/location - I would just rather avoid
having to remember to do a full grep search and replace manually every time
I edit a heading string.
> ok, I was perhaps heading off in the wrong direction before, I think I
see what your saying now.
> You want some kind of text based link which doesn't break when you edit
the components (node headlines) which it targets.
Exactly. The "anchor" would ideally be located anywhere in the body, either
to a specific point or spanning a range of text in the chunk. I just
started with << section heading >> as a well-defined example, and since Leo
nodes can represent any chunk/snippet of text in the output stream (in
effect an "include" macro), present a degree of flexibility.
> UNLs are an example of a text base link, but they break when you edit the
headlines they reference.
As would anything. I started off by asking if a tool existed, or would be
possible:
>> that keeps track and ensures that if/when I change the << section
headers >> text, it automatically does a search and replace throughout the
whole shebang, keeping the other inline references in sync with the
original target.
>> Ideally this would operate on all @ <file> node types, even if they're
not fully "loaded"? Although I concede a problem with @ <file> directives
that aren't supposed to touch the external source, I think there should be
a configurable setting to make this particular automated edit process an
exception.
Let's call this hypothetical tool "FixLinks" - here's the workflow:
- Save the .leo file and confirm the filesystem's in sync
- (make a backup, commit to your VCS, whatever makes you feel secure)
- open the FixLinks dialog and copy the text you're about to edit to
"search"
- edit the text and save the .leo file again
- copy the new string to FixLinks' "replace" press the "go" button
FixLinks now greps the whole directory tree **including** the private
@shadow folders, but not ignoring .svn .bzr etc folders, replacing
oldString with newString throughout.
> I can't see a simple way to make them unbreakable without using clones or
backlinks, which aren't text based.
Well let me go out on a limb here, and not just to solve my little problem,
since I think FixLinks is a generic answer to that regardless of a
Leo-specific implementation, but if my @shadow related comments above hold
true:
Why can't backlinks (or even clones ??!!) now be stored in the private-file
sentinels?
> I guess you could have a routine which checks for impacted UNLs every
time you edit a headline, or re-arrange nodes (which will also break UNLs).
An automated background FixLinks tools would of course be much better than
the above workflow, but even that would take care of the edit a headline
issues. Here's my workaround solution (call me Mr Kludge 8-) for the
location issue.
First I'll bore you with an account of my usual writing workflow - bear
with me, it pertains.
- Anytime I'm going to do *any* data-entry, creating or editing prose
content *anywhere*, it first gets written in my journal, sort of a "global
scratchpad". For that I'm currently using RedNotebook, a python-based
journal cum-editing-applet that stores all its data as plaintext, marked up
with txt2tags and structured with YAML.
- When I'm done with an editing session, I copy the content from there
and paste it into wherever it belongs
- I keep my team's Projects/Action stuff ("to-do's) in Redmine, "hard
landscape" appointments and calendar data in iCal/CalDAV, contact data in a
CRM backed by LDAP store, both integrated with email.
- The rest (reference data, an all-topics "knowledgeBase") is basically
plain text in vary levels of structure, stored in a well-organized folder
hierarchy (much of which in the process of being liberated from my
before-mentioned EvernoteV2 databases.
- I always *copy*, never cut, from the journal database, leaving the
original text there as an archive record for ever, never go back and edit
it, nor refactor/organize it in any way. If existing text needs editing, I
first copy it to RedNotebook and do it there. Sure the journal data gets
huge, but who cares? Once I've finished parsing it for significant data
I'll very rarely ever look at it again unless I really need to, and having
the redundant original data has saved my butt on several occasions over the
years. BTW everything is also under VC and of course well backed up.
Now to adapt this to Leo - I propose a "canonical tree", which is simply
structured by date - YYYY / MM / DD (possibly HHMM, but I wouldn't). All
content gets created there as nodes there first, and that location never
changes. Clone nodes from there to "where they belong", by topic, function
whatever, but always us the master hierarchy location when creating UNLs. I
might even go so far as to copy clones needing editing to today and then
use FixLinks to update my content - intra-leo version control - but YMMV.
To anyone who's followed along this far, I thank you for your patience 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/-/p9E72lFHM8cJ.
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.
