txt2tags plugin
84 views
Skip to first unread message
HansBKK
Dec 20, 2011, 11:42:55 PM12/20/11
to leo-e...@googlegroups.com
Just thinking out loud here, if you're busy feel free to ignore.
If I were to start learning Python by taking on a "little project", I figure it should help extend Leo's capabilities.
My ideas are very much related to this thread, and IMO would greatly extend Leo's abilities in these areas:
However I also want the tool (calling it "t2render" for now) to be more generally applicable, ideally at the OS level, and if possible, and even more ideally, cross-platform. So I'll start my description there, and then work back to how it can be hooked into Leo.
Plain executable, plaintext config file in the same folder in addition to CLI option flags
--------------------
Simplest case (level 0):
Given a *.t2t file - plain text, marked up in txt2tags markup.
- double-click on it, auto-launches t2render, either via editor or OS config
- if it's not plaintext query the user
- if it is, pop a window with a rendered view
- at least show the text, obviously must contain some txt2tags in order to show formatting.
- even in the more complex cases below this is not editable
- like viewing html in a browser,
- or (AFAIK) reST in a viewrender pane.
Non-critical enhancements:
- If the applet is already launched, drag and drop any file (same error-checking as above on filetype)
--------------------
Next level 1, bit more complex:
Txt2tags already has ability to attach a designated stylesheet - obviously CSS in the case of HTML target output. However this is really IMO only suitable for files that are designed to be standalone web pages, rather than the "chunks and snippets" form I currently have many thousands of, and am planning to bring under Leo's management.
So if there is no stylesheet specified in the rendered data, t2render applies the usual CSS cascade/override
- allows a global.css in its config directory that acts as default, or top-level in the CSS cascade.
- --style option at the command line adds another, if no path look in its config directory
- if rendering from a file xyz.t2t also look for
- local.css in the same folder (applies to all files there)
- xyz.css in the same folder (specific to just that file)
- default behavior is to ignore all the above if there is no stylesheet specified in the rendered data, only use that rather than the cascase
- but allow that to be turned off with a CLI option
As to the actual implementation - Txt2tags is written in Python, and apparently can be used as a module by other apps. The only example I've found making use of rendering in a GUI is RedNotebook (also Python-based, not sure how "pure"), which I believe is FOSS so I can use that as a model.
However, to facilitate better integration with Leo and other tools, I think I would actually want to convert the txt2tags data stream to HTML (in memory or a temp file?) rather than rendering to pixels directly, so that I could take advantage of local native features already enabled for that format, e.g. viewrender?
However this might make more difficult the CSS formatting logic above, so perhaps do both at once, not sure.
--------------------
Level 2 - external file conversion, parallel to above rendering, as well as CLI-only usage. These only apply when rendering a file, as opposed to a chunk/snippet coming from Leo. Perhaps it should be scripted from within Leo, but I'd prefer something that worked independently as well.
Txt2tags has many many target output formats (including in the current SVN dev reST!), but here I'll just focus on html as lowest common denominator.
When rendering based on user interaction (double-click, drag-n-drop)
- enable "save file as" to arbitrary location
- automatically convert the file, options to configure choice to place xyz.html target in:
- same folder as source (default)
- a specified location (configurable temp)
- ideally a per-dirtree-configurable **parallel** directory tree
- presumably set in the configfile, although I suppose possible to also create CLI options
- set a "source root" for each source tree
- paired with a "target root", goal is to incrementally mirror the source tree
- if the path doesn't exist in the target, prompt to confirm creation
- don't handle delete/move/renames of source, leave that to the user or Level 3
--------------------
Level 3
CLI option to recursively (delete and re-)create the whole target tree from source.
This can relatively easily just be scripted using Txt2tags native executable, and in fact in my discussions with Terry, this is the process I'm planning on automating with GNU make, perhaps as a cron job.
However I figure this functionality should be enabled as an option for t2render, in order to handle cleaning up from Level 2 operations. If t2render requires installation of txt2tags as a dependency then perhaps just pass through a call
====================
For those taking the time to wade through all of this, thank you. I'm obviously looking for feedback, any suggestions or comments welcome. Some specific questions:
- Does this seem a "challenging but do-able" first project for a total noob to both Python and programming? (not counting batch/scripts, Lotus macros etc 8-)
- Is it practical to create as a Leo-independent tool, but in such a way that it can be tightly integrated?
- I'm hoping to perhaps even provide an alternative viewrender "engine" and basis for a custom @txt2tags node type, ideally paralleling some of the @rst stuff (both of which I know nothing other than that they exist from my reading).
Total side note, but if/when this is done, I'd like to enable similar functionality for AsciiDoc --> DocBook as well as reST or markdown --> Pandocs - I mean hey if you're dreaming, dream big right?
Such possibilities would IMO transform Leo into a "content authoring and open document processing meta manager" whose capabilities haven't been fully imagined by anyone yet. . .
If I were to start learning Python by taking on a "little project", I figure it should help extend Leo's capabilities.
My ideas are very much related to this thread, and IMO would greatly extend Leo's abilities in these areas:
3. A generator/creator of (text) data and documents of all kinds: including, but not limited to, programs, web sites, and .pdf, .html and .tex files.
4. A rendering engine for rST, html and svg and other graphics sources, as well as pictures, svg files and movies included by reference.
However I also want the tool (calling it "t2render" for now) to be more generally applicable, ideally at the OS level, and if possible, and even more ideally, cross-platform. So I'll start my description there, and then work back to how it can be hooked into Leo.
Plain executable, plaintext config file in the same folder in addition to CLI option flags
--------------------
Simplest case (level 0):
Given a *.t2t file - plain text, marked up in txt2tags markup.
- double-click on it, auto-launches t2render, either via editor or OS config
- if it's not plaintext query the user
- if it is, pop a window with a rendered view
- at least show the text, obviously must contain some txt2tags in order to show formatting.
- even in the more complex cases below this is not editable
- like viewing html in a browser,
- or (AFAIK) reST in a viewrender pane.
Non-critical enhancements:
- If the applet is already launched, drag and drop any file (same error-checking as above on filetype)
--------------------
Next level 1, bit more complex:
Txt2tags already has ability to attach a designated stylesheet - obviously CSS in the case of HTML target output. However this is really IMO only suitable for files that are designed to be standalone web pages, rather than the "chunks and snippets" form I currently have many thousands of, and am planning to bring under Leo's management.
So if there is no stylesheet specified in the rendered data, t2render applies the usual CSS cascade/override
- allows a global.css in its config directory that acts as default, or top-level in the CSS cascade.
- --style option at the command line adds another, if no path look in its config directory
- if rendering from a file xyz.t2t also look for
- local.css in the same folder (applies to all files there)
- xyz.css in the same folder (specific to just that file)
- default behavior is to ignore all the above if there is no stylesheet specified in the rendered data, only use that rather than the cascase
- but allow that to be turned off with a CLI option
As to the actual implementation - Txt2tags is written in Python, and apparently can be used as a module by other apps. The only example I've found making use of rendering in a GUI is RedNotebook (also Python-based, not sure how "pure"), which I believe is FOSS so I can use that as a model.
However, to facilitate better integration with Leo and other tools, I think I would actually want to convert the txt2tags data stream to HTML (in memory or a temp file?) rather than rendering to pixels directly, so that I could take advantage of local native features already enabled for that format, e.g. viewrender?
However this might make more difficult the CSS formatting logic above, so perhaps do both at once, not sure.
--------------------
Level 2 - external file conversion, parallel to above rendering, as well as CLI-only usage. These only apply when rendering a file, as opposed to a chunk/snippet coming from Leo. Perhaps it should be scripted from within Leo, but I'd prefer something that worked independently as well.
Txt2tags has many many target output formats (including in the current SVN dev reST!), but here I'll just focus on html as lowest common denominator.
When rendering based on user interaction (double-click, drag-n-drop)
- enable "save file as" to arbitrary location
- automatically convert the file, options to configure choice to place xyz.html target in:
- same folder as source (default)
- a specified location (configurable temp)
- ideally a per-dirtree-configurable **parallel** directory tree
- presumably set in the configfile, although I suppose possible to also create CLI options
- set a "source root" for each source tree
- paired with a "target root", goal is to incrementally mirror the source tree
- if the path doesn't exist in the target, prompt to confirm creation
- don't handle delete/move/renames of source, leave that to the user or Level 3
--------------------
Level 3
CLI option to recursively (delete and re-)create the whole target tree from source.
This can relatively easily just be scripted using Txt2tags native executable, and in fact in my discussions with Terry, this is the process I'm planning on automating with GNU make, perhaps as a cron job.
However I figure this functionality should be enabled as an option for t2render, in order to handle cleaning up from Level 2 operations. If t2render requires installation of txt2tags as a dependency then perhaps just pass through a call
====================
For those taking the time to wade through all of this, thank you. I'm obviously looking for feedback, any suggestions or comments welcome. Some specific questions:
- Does this seem a "challenging but do-able" first project for a total noob to both Python and programming? (not counting batch/scripts, Lotus macros etc 8-)
- Is it practical to create as a Leo-independent tool, but in such a way that it can be tightly integrated?
- I'm hoping to perhaps even provide an alternative viewrender "engine" and basis for a custom @txt2tags node type, ideally paralleling some of the @rst stuff (both of which I know nothing other than that they exist from my reading).
Total side note, but if/when this is done, I'd like to enable similar functionality for AsciiDoc --> DocBook as well as reST or markdown --> Pandocs - I mean hey if you're dreaming, dream big right?
Such possibilities would IMO transform Leo into a "content authoring and open document processing meta manager" whose capabilities haven't been fully imagined by anyone yet. . .
Matt Wilkie
Dec 21, 2011, 3:48:23 AM12/21/11
to leo-e...@googlegroups.com
> Just thinking out loud here, if you're busy feel free to ignore.
>
> If I were to start learning Python by taking on a "little project", I figure
> it should help extend Leo's capabilities.
>
> If I were to start learning Python by taking on a "little project", I figure
> it should help extend Leo's capabilities.
For me, this would be a very ambitious project, actually several
projects. I'd learn a lot but likely never finish. :)
A few unorganized thoughts:
- Leo has command line options and can run in batch mode:
http://webpages.charter.net/edreamleo/scripting.html#running-leo-in-batch-mode.
Meaning if you (or anyone) writes a txt2tags leo plugin it can be
called in response to 2x-click in file system explorer or other event.
- txt2tags has a lot of output formats and it looks like they're eager
for more. It might be easier to persuade (or help) txt2tags output to
rst and then utilize the existing rst plugin for rendering/conversion
than to write a new Leo rendering parser. (or not, I've never written
a leo plugin, maybe it's just easy peasy.)
Here's an easy recipe for launching any external process from a button
inside Leo:
http://leo.zwiki.org/CommandShellHere, "A button to open a command
shell at the `@path` location of the active node". It could be easily
reworked to call txt2tags and feed it the location of the current
@file or contents of the current node.
And finally, I still don't think I know what your end goal is. Assume
t2render is built and viable, that clicking on any one of your twenty
thousand snippets shows a rich text rendering of it. So now what?
What's it for?
Musing some more, I think I'm seeing a desire to be able to edit and
view rich text (for niceness), and save in marked up plain text (for
safety, guaranteed longevity). I think that's a tough nut to crack,
witness the many wiki's and their creole. I was hanging out with
Twiki/FosWiki when they went to great lengths to build an html editor
that would save in their markup. They are successful but it was a lot
of work by several people.
--
-matt
yadhu nath
Dec 20, 2011, 11:56:34 PM12/20/11
to leo-e...@googlegroups.com
sir the data with me is in xcf format is it possible to convert it into .dat form using geo office software?
--
YADHUNATH.E.M
--
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/-/XkMPQhqhDRsJ.
To post to this group, send email to leo-e...@googlegroups.com.
To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
--
YADHUNATH.E.M
HansBKK
Dec 21, 2011, 9:52:34 PM12/21/11
to leo-e...@googlegroups.com
On Wednesday, December 21, 2011 3:48:23 PM UTC+7, Matt Wilkie wrote:
For me, this would be a very ambitious project, actually several projects. I'd learn a lot but likely never finish. :)
Story of my life 8-)
Musing some more, I think I'm seeing a desire to be able to edit and view rich text (for niceness), and save in marked up plain text (for safety, guaranteed longevity). I think that's a tough nut to crack, witness the many wiki's and their creole.
No, I hate wysiwyg myself - the editing via light markup syntax like txt2tags isn't an issue at all.
- txt2tags has a lot of output formats and it looks like they're eager for more. It might be easier to persuade (or help) txt2tags output to rst and then utilize the existing rst plugin for rendering/conversion than to write a new Leo rendering parser. (or not, I've never written a leo plugin, maybe it's just easy peasy.)
It's
true, txt2tags being written in Python, would give me a relevant
learning project and in the end allow for some level of Leo integration
However Leo isn't a "target output" in my workflow, like "web site" "ebook" or "PDF". As **the** meta-organizer, it needs to work with the "master source" files themselves.
It's true there's nothing preventing me from using Leo with txt2tags as it stands now, but getting a viewrendered window to pop up to check a chunk's formatting, would be nice. My post wasn't so much about "how can I get Leo to do x" - I intend to accomplish these things in a way that they will also be useful independently of Leo. If this is done simply by being able to trigger external scripts and tools that's fine, thanks for the pointer to CommandShellHere.
I just figured since txt2tags is a "modularized" (?) Python tool, I might as well try to enhance Leo's capabilities itself, perhaps thereby promoting its use as a documentation "meta manager" (Edward's points 3 and 4). More on that follows, summarizing from my "introducing myself" thread (long) and this and here
However Leo isn't a "target output" in my workflow, like "web site" "ebook" or "PDF". As **the** meta-organizer, it needs to work with the "master source" files themselves.
It's true there's nothing preventing me from using Leo with txt2tags as it stands now, but getting a viewrendered window to pop up to check a chunk's formatting, would be nice. My post wasn't so much about "how can I get Leo to do x" - I intend to accomplish these things in a way that they will also be useful independently of Leo. If this is done simply by being able to trigger external scripts and tools that's fine, thanks for the pointer to CommandShellHere.
I just figured since txt2tags is a "modularized" (?) Python tool, I might as well try to enhance Leo's capabilities itself, perhaps thereby promoting its use as a documentation "meta manager" (Edward's points 3 and 4). More on that follows, summarizing from my "introducing myself" thread (long) and this and here
And finally, I still don't think I know what your end goal is. Assume t2render is built and viable, that clicking on any one of your twenty thousand snippets shows a rich text rendering of it. So now what? What's it for?
Knowledgebase composed of "snippets" and "chunks", some topic domains in various stages of transformation from
- raw draft fodder --> organized "sections" "posts" "articles" --> domain knowledge base --> "book"
- data --> information --> knowledge (ultimately intended to contribute to wisdom 8-)
Most of this is locked up in a few dozen Evernote 2.2 files 8-(, currently in various stages of transformation to
- plain text files stored in filesystem directory trees as "primary axis of organization"
I plan for this latter process to be the final storage format for my data, I no longer want to "lock it up" in a format that requires conversion.
This format is fully transparent, as "permanently open" (future-proof) as it gets, open to both read and write access by a much wider range of tools than any other.
This stance recognizes that the former process is the permanent one, and 90+ plus of the data (which grows every day) will remain at the lower levels; only a tiny fraction is even worth the trouble of "write-access" revisiting and just needs to be easily accessible via search among the group.
Leo is one of very few tools that allows me to keep the "content" data in that format **at the same time** as allowing me to rewrite and most importantly "play around with" its organization - think of shuffling index cards when writing your dissertation. Cloning lets me have different views of the same text, re-used cross-referenced/ing chunks in different topic domains or different higher-level "articles" and "books".
Even when this process is "done", the text is now accessible via what I call alternative "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. DRY documentation - really "knowledge base management".
For a tech doc, - 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, only have to update in one location - separate output trees by software version!
All this while still keeping all the data (master source chunk/snippet files as well as Leo-generated organized output stored out in the filesystem as plain text. If one day Leo disappears, or I want to use whatever textproc tools might come along in parallel, no need to export/import/convert the data itself.
Now add the Leo's unique ("DAG"??) storage mode, exposure to both customized scripting and standard external tools and it becomes
- raw draft fodder --> organized "sections" "posts" "articles" --> domain knowledge base --> "book"
- data --> information --> knowledge (ultimately intended to contribute to wisdom 8-)
Most of this is locked up in a few dozen Evernote 2.2 files 8-(, currently in various stages of transformation to
- plain text files stored in filesystem directory trees as "primary axis of organization"
I plan for this latter process to be the final storage format for my data, I no longer want to "lock it up" in a format that requires conversion.
This format is fully transparent, as "permanently open" (future-proof) as it gets, open to both read and write access by a much wider range of tools than any other.
This stance recognizes that the former process is the permanent one, and 90+ plus of the data (which grows every day) will remain at the lower levels; only a tiny fraction is even worth the trouble of "write-access" revisiting and just needs to be easily accessible via search among the group.
Leo is one of very few tools that allows me to keep the "content" data in that format **at the same time** as allowing me to rewrite and most importantly "play around with" its organization - think of shuffling index cards when writing your dissertation. Cloning lets me have different views of the same text, re-used cross-referenced/ing chunks in different topic domains or different higher-level "articles" and "books".
Even when this process is "done", the text is now accessible via what I call alternative "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. DRY documentation - really "knowledge base management".
For a tech doc, - 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, only have to update in one location - separate output trees by software version!
All this while still keeping all the data (master source chunk/snippet files as well as Leo-generated organized output stored out in the filesystem as plain text. If one day Leo disappears, or I want to use whatever textproc tools might come along in parallel, no need to export/import/convert the data itself.
Now add the Leo's unique ("DAG"??) storage mode, exposure to both customized scripting and standard external tools and it becomes
> a "content authoring and open document processing meta manager" whose capabilities haven't been fully imagined by anyone yet. . .
Sorry to rave on, most likely a more complete answer than you wanted 8-)
HansBKK
Dec 21, 2011, 9:57:38 PM12/21/11
to leo-e...@googlegroups.com
On Wednesday, December 21, 2011 11:56:34 AM UTC+7, yadhu nath wrote:
1. Is this the right place for you to ask this question? I've never heard of these terms in relation to using the Leo editor.sir the data with me is in xcf format is it possible to convert it into .dat form using geo office software?
2. Usually a good idea to start a new thread when posting on an unrelated topic
Good luck. . .
Reply all
Reply to author
Forward
0 new messages