(Opinions are my own)<p>I like the ideas behind this but I do not think this will take off as much as CommonMark has. My main reasons for thinking this:<p>1. Users don't really care about edge cases. CommonMark (cmark-gfm really) is "good enough". If something looks odd people go "oh, strange" and make a 3 second edit and forget about it.<p>2. There's already multiple parsers for every language for markdown. Here there is a single Lua implementation.<p>3. GitHub is the king.<p>If it cannot render in GitHub it's not real. If it's harder for me to write in the 99% case then it's not worth it. If it's harder for me to implement within my application then I'm too lazy to switch.<p>Nice things in here:<p>1. Less ambiguous parsing. For the parser infrastructure I support at $JOB this makes supporting questions from users a HUGE pain in the ass.<p>2. AST-first design. Seems like everything appears in the AST (even references!) which is a huge win over cmark-gfm. There's also source positions included which is a MASSIVE win for tooling.<p>3. Custom Attributes implementation. This is really nice for extensibility. It is less readable but having it as an option is nice.
I recently found out that the author is John MacFarlane, a philosophy professor I have read papers from in totally unrelated contexts. I was more than surprised to see that he is the original author of pandoc. It boggles my mind how someone with an academic career in a somewhat unrelated field can have a GitHub profile like him. It's really impressive.<p>On topic, though, preceding sublists with empty lines is a complete non-starter for me. However, since I don't hard-wrap lines (goal 7), but use soft-wrap only, I am not in the target audience anyways.
I understand the rationale and how CommonMark parsing is not trivial and could be simplified, but the resulting language misses, for me, the best part of Markdown: that it happens to be <i>pretty much</i> just what I'd write in plain text anyways.<p>The odd newline requirements on lists and blocks, the special syntax for raw HTML and so on makes Djot feel more artificial to me.
> In djot, we just get rid of indented code blocks. Most people prefer fenced code blocks anyway, and we don't need two different ways of writing code blocks (goal 11).<p>Sensible. Mostly since it makes other things easier (goal 5), second because one thing is only represented in one way, and thirdly (least important) since indented code blocks are kind of a pain to format compared to fenced code blocks.
So this is what happened to the energy that had been going into CommonMark. I'd been wondering, because the spec releases for CommonMark have been slowing down for quite a while [1], and it felt like certain issues just never saw attention [2]. I'm glad that energy didn't just dissipate and actually went into something useful.<p>On a practical level, nearly everything this does is better served by Pandoc Markdown today. But maybe in some not-so-distant future I'll be able to make use of this.<p>[1]: <a href="https://spec.commonmark.org/" rel="nofollow">https://spec.commonmark.org/</a><p>[2]: <a href="https://talk.commonmark.org/t/issues-we-must-resolve-before-1-0-release-6-remaining/1287" rel="nofollow">https://talk.commonmark.org/t/issues-we-must-resolve-before-...</a>
This looks pretty intersting. Besides, I find it fascinating how jgm apparently is happy on both sides of the "typed language" spectrum. pandoc in Haskell, and djot in Lua. True, pandoc has acquired a lot of Lua in the recent years, but still. I wonder how it feels switching from the cozy safety of a language like Haskell, back to the "good old" interpreter days. I personally have dropped writing anything larger then 1k lines in a dynamic language. Have been bitten by my own inconsistencies too much in the past.<p>I wonder what someone like jgm has to say about the difference of writing Haskell and Lua.
Given the ubiquity of Markdown, and how painful it is to build a completely compliant parser, I really hope Djot (or something like it) would take off.<p>Shame that the creator of Markdown blocks any efforts to to fix or standardise the format.
Most excellent!<p>If Github supported it alongside markdown, this would drive the markdown parsers to support this as a flavor, and then the community could decide; it will be fascinating to analyze the open-source population.<p>I'm finding dozens of applications for a lingua franca of mildly-structured, human-readable language that transforms as easily into data as documents and UI's. I've built out 10+ markdown applications using 3-4 parsers, and always had to reduce the effective semantics to a small subset of features, and then had to use metadata or convention to do what attributes will do much more cleanly.<p>As for Lua: yes it's the best for integrating into pandoc <i>performance-wise</i>, but ay! the table structures and metadata tables to get anything like typing are mind bending, and I am still miffed at being blocked at a critical time by a bug in pandoc's lua initializer for tables.<p>Aside language/stdlib developers, jgm is my greatest benefactor, and he deserves a cadre of loyal and competent implementors.
look forward to having standardized e.g. "figure captions", looks like it's being worked out here <a href="https://github.com/jgm/djot/issues/28" rel="nofollow">https://github.com/jgm/djot/issues/28</a><p>pandoc is interesting because with markdown it currently converts the "alt text" for figures  in markdown->pdf conversion into the figure captions, which is cool but makes me think: it is not alt anymore, anyone should have it
I never realized the problem with markup until that phrase "light markup". The problem is that it's designed for a human to edit it by hand with a text editor. It's a programmer designing for a programmer, rather than for a user. It's a plumber designing a sink. A mechanic designing a radio. A busboy designing tableware.<p>What we should have instead of markup, is a WYSIWYG with keyboard shortcuts. Confluence, for example, will convert Markdown into rich text in real time, and has keyboard shortcuts for its other layout/style options. But the point is to edit it in a GUI, see your changes live, and not need to learn a language in order to edit a document. There are so many problems you avoid by giving the user tools to make their life easier. Markup may be one tiny part of that, but it shouldn't be considered the complete solution.
As someone who's been using Markdown since before it was cool, I love it! I think writing the implementation in Lua is an interesting take since Lua out-of-the-box does not support standard regular expressions; it instead has its own pattern-matching thing which is a bit more limited. But it looks like they've embraced that limitation to force themselves to write something that doesn't need a full regex library to be sanely parsed.<p>My biggest complaint is that asterisks map to <strong> and underscores map to <em> (in HTML terms). This is not backwards-compatible with Markdown where (asterisk)foo(asterisk) gets you <em>foo</em>, and it feels objectively backwards, if that makes sense. I wonder if there's any chance they could reverse that.
The odds of replacing markdown and all it's issues seem nearly impossible given its ubiquity and I've run into many of those problems but, this seems just as arbitrary in many ways,<p>For example:<p>> Block-level elements can't interrupt paragraphs (or headings), because of goal 7<p>It then goes on to show they do interrupt paragraphs<p><pre><code> - this then - this other thing
</code></pre>
vs<p><pre><code> - this then
- this other thing
</code></pre>
The 2nd is 2 list items but it's just the first with being interrupted by a block-level element.
Love it, will see how many places I can get this introduced. The things that pissed the author of this off are precisely the things that piss me off. Unconcerned with the newlines in list syntax; that's how I'd write them myself, anyway. I like many things about this, including the various uses of curly braces.
Wow, this is all I ever wanted. The only thing that's maybe missing is a natural way to do captions for images and tables, and a syntax for spoilers. But these can probably be built on top of the div and span syntax.