Offray, Your message was a nice holidays present for me, thank you.
On Wednesday, December 28, 2011 11:59:54 PM UTC+7, Offray Vladimir Luna Cárdenas wrote: > > Personal Learning Environment[1] which includes Leo as a tool for their What discipline are the students? You said non-programmers, but are they studying CS? If not I think you will need to provide a "canned" pre-installed environment (see below), including pre-populated .leo files, along with some detailed how-to's and examples to get them started, if at all possible actually walking them through hands-on demos with them following on their own desktops. Is it a big group? Do you have access to a computer lab? Without such hand-holding you might get some blowback over "forcing" them to use a tool with such a steep learning curve. Maybe even if they are CS such an approach would IMO probably be a good idea. > For me lightly marked-up text is also the key for data sharing and editing > with other people who are not Leo users. I would prefer txt2tags > markup over others because of lightness and easiness to learn and to > create custom exporters, but the of support for references (footnotes, > biographical data and others) keep me in reStructuredText which is still > nice with some minor glitches solved by Leo (like underline as a markup > indicator). So reST will be my format for writing text in various > infrastructures and exporting from it to several formats > In my case, I'm not letting my choice of syntax for the master source be determined by any one tool in the chain. reST/Sphinx IMO is currently just too limited in its choices for target output. If I can find a path from reST to DocBook, maybe, but I think more likely to use txt2tags, or maybe pandoc's extended markdown and go from that to reST where it's needed. Note I'm only using txt2tags for the "snippet/chunk" level, it converts to AsciiDoc once the topic domain becomes a target for a large structured work - in real-world terms, when you get beyond a collection of articles and want to compile something approaching a book. There really isn't any downside to using Leo to manage whatever arbitrary markup, text is text after all. Using independent tools to assist with writing the codes and to generate previews is just "nice to have", not necessary. And keyboard macros, scripts that snap-convert @ <file>s to html with scripting is easily done at the OS level and integrated with Leo. I hope to figure out how to render node content directly, independently of @ <file> output, but that's just a convenient gee-whiz maybe-one-day possibility. > That being said, the more I live in Leo, the more I see plain text with > markup and files in general as a "degradation" of the meta-structure that > Leo provides to the plain files world. Now I'm trying to add even more > structure to that flat-word with Leo + Fossil. The first one gives files > flat word structure in space, the second one in time. I don't see myself > going back to flat world, but I know that I need to communicate with people > who is still there, so I degrade the Leo metastructure to this kind of > minimal comfortable standard for communication. > Interesting POV, for me a bit of a stretch. When the source content is very dense/complex/large, I'm finding Leo very helpful to further my understanding, but I see it as a tool for "re-mixing a mashup" in order to publish what you call "flat" content, rather than expecting others to navigate my outlines themselves. Now sharing outlines with other developers/content editors, that would be great, but not the end-user audience. However I do need to dispute your use of the term "flat" - the output formats allow for different sequence "views" for different purposes and audiences, each with their own linking ToC's, extensive cross-reference hyperlinking, including to and between glossaries, multiple topic indexes (tag pages) etc. as well as of course external citation and live-link URLs. A well-designed CHM file or Tiddlywiki is much more useful than dead-tree hard copy, and in fact I would argue much more useful than a .leo file in most contexts. BTW please post some details as to how you're implementing such cross-reference links and or tagging views, I'm not currently implementing these within Leo, only in the target output, via "snippets" interleaved with the main source texts. Keeping the master source data as easily-accessible plain-text is essential to me, and not because I think Leo will disappear. Or at least I know it will, just as I will too one day, but that's not the main reason. The more immediate reality is that I'm only actively re-working a tiny fraction of the data at a time, and often leave off from one topic area and move on to another without "finishing", i.e. generating polished output to a target format. In the meantime, all of the content needs to remain readable and open to others and whatever tools they use. By the time I get back to a given topic domain (set of folders), it is likely some elements of my toolchain has changed, or perhaps other developers/content editors need to be able to pick up where I left off, and I'm not in a position to dictate tool choices to them. a. Installing Leo, which is specially difficult for non-programmers like my > students. I will try to prepare my classes dealing previously with > that problems using alternative installing strategies not found here until > now like pyinstaller[2] and/or Zero Install[3] > No need - everything necessary can be pre-installed to a "portable apps" structure and then just copied to student PCs. Some elements don't install that way by default, but anything their setup routines write to the windoze registry isn't important, and environment variables can be created by launcher batch files. I work this way myself, keeping both data and working environments in sync on multiple desktops. A side benefit is that continuous multiple-location backups become part of the daily workflow (but of course don't substitute for proper structured backups, just reduce their required frequency). Get both a regular Python installation (say to C:\Python27\) and "Python portable" installed to an external hard drive (for me "E:\PortableApps\Common\Python27). Use whatever recursive diffing tool you prefer (mine is winmerge) to get the two trees in sync, apparently wiping non-matching .pyc files is fine, confirm everything is OK on both trees - best to confirm the portable side by running it on another PC without Python - here's where you create batch files modifying your %Path%, setting %HOME% and others your tools may need (I'm also incorporating cygwin and MinGW for the windoze-native build/compiler toolchain (make will automate my text-processing toolchain). Now for any pre-requisite packages that don't ship with a "non-installing" zip package (= "portable"), just run the regular .MSI or setup.exe installation routine to your hard-coded python location (C:\Python27) and replicate it over to the portable side with your diff tool. Since the portable side is the one you'll be working in, keep that as your "master source" for configuration, and remember to keep each side in sync if you update a program on the other. The portable installation can simply be copied and used to any location on any drive on any other windoze PC. If you're planning on sharing files between the various instances, I highly recommend Unison as a sync'ing tool, in combination with a good diffing tool this will allow any-to-any updating - most manageable via a hub-and-spoke topology, but ad-hoc any-to-any "mesh" is also do-able - they key is doing the sync'ing frequently enough to keep the changeset manageable. And of course you can only merge easily diffable files, which rules out the Leo outlines themselves unfortunately. Or you could use fossil for managing the program folders as well as the data, why not? > I imagine a world where deconstructing textual computer interaction the > Leo way would be the standard. We're far away, specially with Leo > self-fulfilled prophesy of being a developer's tool for developers, but > carrying Leo to new contexts will be a way to explore the path to > futures like that one. > We live in different worlds - in my case I dream of one where belief in the power of spirits and ritual magic doesn't dominate daily life. Most people I interact with offline don't read more than a page's worth of text in a month, are in fact lucky to be able to read their own language at all, and are primarily concerned with what they're going to eat today and tomorrow. However in any context, I believe that communicating complex ideas requires both tailoring the content for, and using an easily accessible carrier medium appropriate to the target audience. Leo appears to be "the tool" for me ATM for managing my master source data and helping getting it into various target formats, but can't see my way to actually using it as the message carrier medium itself. But if I'm ever trying to communicate a complex message to programmers, it would be a fun experiment! 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/-/UXHC1jq50iYJ. 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.
