I tried to reply twice - innocuously - but the system deleted my posts immediately. That hasn't happened on other threads. Anyone understand why?
Hi,
This is a no so long detour on a sightly related matter on how we
are using Markdeep for our documentation purposes. At the end, I
offer some insights of what could be useful if such workflow would
be implemented in Leo or LeoInteg.
I have been using Markdeep as a way to create data narratives that combine prose, code and screenshots/graphics, like this one, that is relatively long[1] and uses several features of Mardeep including automatic table of contents, admonitions, code blocks, images with legends and so on. Using Markdeep was a way to port the lessons learned with Grafoscopio(2015)[2] (my own outliner attempt trying to combine inspirations from Leo and Pharo/Smalltalk, among others).
Our explorations of plain text and human/diff friendly formats to
store long/complex documents resonate with the ones of Clojure's
Clerk[3][3a], Elixir's Livebook[3b] or even Jupytext[3c], despite
of the last one being more an afterthought to deal with the
problems of Jupyter's long nested JSON as storage representation
of computational documents. But we started before such attempts,
by storing Grafoscopio's computational notebooks as STON
documents, with embedded Markdown inside (STON[4][4a] is a JSON
inspired object serialization format with several added
advantages). With the launch of Lepiter powered computer
notebook[5], my idea was to invert the process, putting STON block
inside Markdeep documents, with the added benefit of our readers
not needing to have Grafoscopio, Pharo or GT installed to read our
data narratives and also having a light format for publishing and
exchanging such documents, which is pretty aligned with
UrbanUnPlanner's intend of collaboration without external
compilation steps with external people. For example, here the
original Grafoscopio STON document[6] and its equivalent Markdeep
translation[6a]. AFAIK, we, at the Grafoscopio community, are the
only ones using Markdeep as a format for data narratives. And it
has working pretty well, despite some Markdeep bugs we have found
and reported to its author by email, as the Markdeep repository
has no public issues.
Adopting Markdeep was kind of straightforward in our use case: just traversing the document tree and adding the Markdeep first and last lines, and I think something similar could be done in Leo. What has been pretty useful is also to have a web preview of the document running in localhost. Something similar, implemented with some minimal server, like Flask in Python's case or the equivalent for VS Code/Codium could be pretty helpful for authors using Markdeep from Leo and wanting and agile preview of their documents.
Cheers,
Offray
== Links
[1]
https://mutabit.com/repos.fossil/gig/doc/trunk/wiki/en/gig-portable-wiki--1apbv.md.html
[2] https://mutabit.com/grafoscopio/en.html
[3] https://clerk.vision/
[3a] https://book.clerk.vision/
[3b] https://livebook.dev/
[3c] https://jupytext.readthedocs.io/en/latest/
[4] https://github.com/svenvc/ston/
[4a] https://github.com/SquareBracketAssociates/Booklet-STON
[5]
https://lepiter.io/feenk/introducing-lepiter--knowledge-management--e2p6apqsz5npq7m4xte0kkywn/
[6]
https://mutabit.com/repos.fossil/indieweb/file?name=indieweb.ston&ci=tip
[6a]
https://mutabit.com/repos.fossil/indieweb/doc/tip/indie-web--25zqu.md.html
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/81d06694-5f7c-493e-8f23-9caf005e517cn%40googlegroups.com.
... What has been pretty useful is also to have a web preview of the document running in localhost. Something similar, implemented with some minimal server, like Flask in Python's case or the equivalent for VS Code/Codium could be pretty helpful for authors using Markdeep from Leo and wanting and agile preview of their documents.
Yes a static web server that serves the pages produced by an @markdeep node would be pretty useful. The exportation process could add the Markdeep custom metadata and use node levels (relative to the @markdeep node) to indicate sections and subsections.
Cheers,
Offray