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<https://groups.google.com/d/msg/leo-editor/-H7s2LFuPWQ/yrqPXyJhxGsJ>, 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. . . -- 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 [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.
