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

On 20/11/23 23:57, UrbanUnPlanner wrote:
Since it seems the moderation ate my last attempt at posting, here we go again.

I am looking to use Leo to help me organize an upcoming writing project, and also found (through this group, even) the Markdeep (https://casual-effects.com/markdeep/) authoring format and went "hey, this looks suitable for my purposes." Furthermore, that brought me to Leo's @auto support for Markdown, which made me think "great! I can use that to let me collaborate with people who are using other tools".

However, in order to achieve its polyglot capabilities (both editable as Markdown-style text _and_ viewable in a browser without any offline build steps), Markdeep relies on a trailer line of HTML.  To my chagrin, however, Leo's @auto functionality is not compatible with the normal @last mechanism for placing trailer lines into output files.

So, what should I do to get that trailer line to reliably output at the end of the @auto generated file, especially if I want to use a clone node to provide a single source of trailer truth across multiple @auto files and want to be able to roundtrip manual edits back into Leo?
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/81d06694-5f7c-493e-8f23-9caf005e517cn%40googlegroups.com <https://groups.google.com/d/msgid/leo-editor/81d06694-5f7c-493e-8f23-9caf005e517cn%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b3d8bf85-0ae9-4653-b0ea-ca44ac6e56a1%40riseup.net.

Reply via email to