On Dec 10, 11:24 pm, "Edward K. Ream" <[email protected]> wrote: > There are many interesting ideas in this thread. Many thanks for your > remarks.
And thank you for your patience as I continue to clarify my needs and goals with Leo - I hope to take advantage of the tool's flexibility to be able to "push the envelope" toward more functionality for and usability by non-programmers. I realize my needs are edge cases relative to the current typical Leo user, but ATM I'm looking at it as a black box, a processing and organizing tool **between* the specific endpoints outlined at the end of this post. At every point in it's journey from one stage to the next, the data must remain (a huge pile of) lightly marked-up plaintext. I am realistic in that I and our users are not creating many "finished"/published large works, 99% of the data will remain "in the process" of being added to, incrementally better organized, re- drafted, but used for our own reference as a somewhat chaotic but nonetheless valuable knowledge base. My goal is to recognize that both myself and Leo won't be around one day, to create a knowledge management/processing system contingent on the working premise that either or both can disappear **at any given point in time** without affecting the "fully open and transparent" nature of the data itself; it should remain at every stage fully accessible and usable to other relatively non-technical writers/ readers/editors/format-processors, and whatever common tools they are familiar with. I **do not** want Leo's XML to become "yet another storage format" for anything other than temporary working data for a specific transform process, because then the usability of the data itself becomes dependent on that specific tool. I would also prefer use relatively simple and open transform methods > 1. All Leo nodes have a "gnx" (Global node index) that is guaranteed to be > immutable and unique. It is easy to access a node's gnx, using p.gnx. Easy - for programmers. >> "internal meta" data structures (p/t/v whatever, all greek to me) >> I'd prefer something actually stored (ideally discreetly) in the plaintext >> content >> clearly visible and open to manipulation in Leo's UI without programming; I >> don't know from python. UNLs seem to be a better fit for my needs at the moment. > 2. I had forgotten about AutoHotKey. Using it is a clever solution for > non-programmers. Nothing to apologize about. However, Leo's own scripting > language is considerably simpler for programmers. Yes - for programmers. ============================== What follows is simply repetition and clarification of my current specific use case - feel free to skip. Stage A - a huge pile of lightly marked-up plaintext data This requires continuous editing and markup, transforming over time into better structured "single-source master" - stage B - plaintext data. By better structured, I mean containing markup that allows for things like internal cross-references, footnotes and glossary entries, and most importantly, topic indexing, both for traditional end-matter indexes and (somehow) backlinking "anchors" visible to the reader close to the inline source content to show what terms apply to the current "chunk" of text - AKA "tagging". Another aspect is the granularity of "chunking" for content re-use, the ability to create different entry points and navigation paths through the content for different context/purposes, e.g. - intro/overview for noobies vs systematic reference for experts vs specific howtos, tips, FAQs - different product/software versions - core vs plug-ins - business rules vs user input vs presentation formatting I then want to be able to (relatively automagically) process these texts into various output target publishing formats, getting as much of the above functionality as possible out of each output structure. Examples - DocBook XML, HTMLhelp, EPUB/mobi ebooks, website, PDF and of course beautifully formatted dead-tree hardcopy - stages C1 to infinity and beyond. -- 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.
