To meet modern requirements and make documents dynamic, we need a flexible API and integration with contemporary frameworks. Simple HTML just isn't up to the task. Although this was the approach during the early implementation (https://github.com/zag/js-pod6), it turned out to be a dead end.
The existing typescript implemetation builds a complete AST (Abstract Syntax Tree), over which middlewares are run in several passes. Yes, there are multiple passes over the tree. This is necessary, among other things, to build a table of contents (TOC).
thank you
Might not work for my use case then. djot is single-pass so dovetails better with forth-style languages.
I do like the blocks and mistake marking though :)
Interesting. Have you been using djot for anything substantial, like technical/academic publishing, large projects like entire books, or similar? How does it fare and what is your toolchain? Thanks in advance!
I'm trying to use it as part of a new forth-style language, hence the need for single-pass.
I've found it as easy to use as markdown, but more regular ie. Well defined, which suits a language spec.
The key parts for me are reference links for execution-thread documentation and ``` blocks to program literally, (and separate/scope comments // from documentation """)
The toolchain as such is just part of the language- the compiler needs to parse djot. I'm not fully there though.
What I find most interesting is that there’s no need to choose between Podlite and Markdown; you can use both and switch between them as needed.
I think Podlite could be really useful in document management systems and electronic publishing. But... let's see what practical uses Podlite will find.
That playground is cool. I wonder if there are any 2-way playgrounds where the right side is also editable using a Word / Google Docs style interface (and the changes are reflected in the code-style interface on the left). I've always wanted something like that for teaching non-technical people the basics of Markdown. Bonus points if it's collaborative.
This is a wonderful and highly sought-after idea. However, it requires significant resources, so we will definitely come back to it and implement it. Thank you
Yeah I get that markdown is included in its own block, was just thinking about the non-markdown syntax and really what the plan is in general - i.e. are you looking to keep pod6 compatibility or are you looking to use the overall style but maybe deviate from the some of the basic standards.
Ahh, yes, of course, there are no dogmas here, I think all options are possible.
After all, this is just the beginning of the journey I think for Podlite )
To meet modern requirements and make documents dynamic, we need a flexible API and integration with contemporary frameworks. Simple HTML just isn't up to the task. Although this was the approach during the early implementation (https://github.com/zag/js-pod6), it turned out to be a dead end.
thank you