On Nov 30, 11:49 am, Terry Brown <[email protected]> wrote:
> On Tue, 29 Nov 2011 20:18:02 -0800 (PST)
>
> HansBKK <[email protected]> wrote:
> > Please let me know if there's a way to accomplish this that I haven't
> > found - I don't like the fact that the backlinks' tags, bookmarks etc
> > are "hidden in the meta", I want to put these relationships if not in
> > the content itself (not sentinels, I love @shadow) but perhaps in a
> > delimited header/footer? Or at least in **my** meta-data text files I
> > mentioned kept separate but somehow tied to the content files -
> > parallel filesystem?
>
> Hmm, "the meta" is basically each node's so called "unknown
> attributes", aka uA aka p.v.u, a python dict of anything.
<snipping most of the programmer-speak>
> child node for a node with a backlink might look like:
>
> {'_bklnk': {'links': [('S', 'tbrown.20111123112137.16198')]}}
> Can you give more specific examples of stuff hidden in the meta which
> you don't want hidden in the meta?
This will seem completely disconnected from what you're talking about,
but is more in line with what I'm trying to figure out how to do in
Leo.
Dokuwiki doesn't use any database - it stores its data files as
plaintext in the filesystem ("pages" subdir), and stuff like creation
date, author, indexing, revision history etc. in separate subdirs
("index", "meta" and "attic"). Some of the DW plugins used for cross-
reference linking, building up navigation hierarchies etc store their
data in meta, but I found this one:
http://www.dokuwiki.org/plugin:subjectindex
that lets you put strings like this anywhere you like in your text
(e.g. an invisible comment block)
{{entry >books/fiction/writing novels|-}}
{{entry >1/book/binding|}}
{{entry >2/books/fiction/writing technical documentation|Writing
Docs}}
Such an approach means that if the "containing/organizing"
infrastructure (Dokuwiki on the one hand, here Leo) were to just
disappear, the core content data itself would remain intact and just
as useful, not only as independent "chunks" of text, but in this case
with the inter-relationships as well.
You can use whatever text processing tools you like to refactor,
script/generate, translate, whatever on the source data, wipe out the
Dokuwiki/Leo - specific meta stuff and rebuild it with the cross-
references still intact.
The above plugin is originally designed for automating the creation of
traditional end-matter indexes, or newfangled "tagging" pages -
they're actually the same thing other than presentation style, and the
fact that latter make backlinks explicit somewhere in the main
content.
But they can also be used for alternative (what I call) "axes of
access" - usually a "book" has a single sequence to navigate from
front to back, chapter 1, 2 etc. However if I have a "source text"
with that as a primary nav, as a teacher I may want to present the
student with a "study guide" sequence + meta-commentary, an
alternative path through the material without actually copying/
repeating the source content. Think of a pile of docs relating to
software - structure an "introduction to concepts", a "getting started
howto", a "how to contribute code" and "complete reference" for
developers, etc, recycling a lot of the same text.
I'm thinking Leo can be a tremendous tool for such an approach to
writing - techdocs are just one context of course, but any sort of
knowledgebase example will do.
Leo's internal ("meta") solution for this is cloning, and from my
current noob POV is perfect for **me** to use in selecting/arranging/
sequencing the source "chunks" of text for a given purpose/audience.
But each target output format (I'm thinking DokuWiki, HTML, LaTeX to
PDF, AsciiDoc to EPUB/mobi) has its own separate way of representing
the various cross-referencing relationships between the chunks
(footnotes, index terms, inline see-also's, glossary entries etc). I'm
trying to work toward ways to represent these structures **within**
the content files themselves, and my current thinking is, if Leo is
the master source container/organizer, to make use of it's "node" as
the lowest unit of "chunked" text. In other words not worry about
targeting a specific spot within a node, just target the node's title.
And the << section name >> construct seems like a good way to go,
already used for the sequencing/navigation/ToC idea. One text file can
have a "See also: << book/binding >>", and as long as that link source
got updated at the same time as the target heading text, it should be
usable for transforming into whatever each output format requires.
My goal is to *not* make use of structures that are specific to Leo,
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.
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.
Sorry my brain doesn't fit the programmer's thought modes, I realize
my thinking here is very vague and unstructured. . .
--
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.
