Hi,
On 24/10/17 03:50, Edward K. Ream wrote: > On Mon, Oct 23, 2017 at 6:59 PM, Offray Vladimir Luna Cárdenas > <off...@riseup.net <mailto:off...@riseup.net>> wrote: > > I second Terry's idea of going with Markdown, particularly Pandoc's > variant, which is pretty mature and with an active community > discussing > a lot of details to support a complete writing & publishing workflow, > the ubiquity advantage with a lot of variants everywhere (Ghost, Stack > Overflow, GitHub, Fossil). > > > Some of Leo's recent documentation files use @language md. See this > FAQ entry > <http://leoeditor.com/FAQ.html#how-can-i-create-and-use-markdown-files>. > As mentioned in this FAQ, I use @button make-md-heads to generate a > TOC. Perhaps this process could be automated. Yes, I know that @language md is available. I'm trying to suggest better integration making Markdown (Pandoc's variant) the default choice for documentation, following Jupyter (and almost every body else example). I'm generally against ad-populum argument (something is good, because is popular), but in the case of Pandoc's Markdown, I think they have > > Recently, at our local hackerspace [1] we > opened the Data Journalism Handbook [2][2a] as a Grafoscopio document > and produced a PDF (13 Mb) [3] from a Pandoc's Markdown file > (500Kb) [4] > generated from a single Grafoscopio notebook/outline (600 Kb). This > workflow was pretty well supported by Pandoc's Markdown. > > > It's difficult to follow the links because I don't understand Spanish. You don't need to. We have make an English translation available in the repository [1], for the general introduction, but we follow a "local first" approach, favoring local language and culture, which seems reasonable after (mostly) teaching myself English to become part of several communities and experimenting first hand the English monopoly in science and tech (see a critical look at [2]). The important issue is that you can produce a nice looking long PDF from a single small, self referential & programmable outline file, using what Pandoc and such (Leo inspired) outlining technology has to offer. This is not available now in the Jupyter world and you need to go with the pile of files approach. That's why offering bridging powerful Leo outlining and Jupyter is important. [1] http://mutabit.com/repos.fossil/mapeda/ [2] https://aeon.co/essays/how-did-science-come-to-speak-only-english > > > > I proposed some Qt Web technology to show markdown (including math) > inside Leo nodes. Maybe the IPython Qt Console, which supports this > rendering could be inspiring here[6], but I don't know about the math > rendering support in that case.. > > > Exactly. I have been thinking of "borrowing" the IPython Qt Console > approach. Iirc, there are many complex details behind the scenes > involved in piping the results to the console. Such details may be > simpler within Leo, or not. > > In any event, the general goal is to make /all/ rendering as simple as > possible in Leo. This is why I am proposing that we read the users > manuals for other systems, looking for /goals/. Only after we have a > clear idea of what we want does it make sense to look into how to do > it. This was an Aha that came to me on vacation. > Seems clever. I keep an eye on Jupyter, Clojure, Org Mode, Leo, Haskell, and curiously, indie video games, by browsing manuals and looking videos and this is an important source of inspiration for Grafoscopio. Cheers, Offray -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
