# Djot: A light markup language by @jgm **URL:** \ **Category:** Spec\ **Created:** [July 12, 2022, 1:13am UTC](https://talk.commonmark.org/t/djot-a-light-markup-language-by-jgm/4229 "2022-07-12T01:13:40Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![vas](https://talk.commonmark.org/user_avatar/talk.commonmark.org/vas/32/1267_2.png) [@vas](https://talk.commonmark.org/u/vas)\ **Post date:** [July 12, 2022, 1:15am UTC](https://talk.commonmark.org/t/djot-a-light-markup-language-by-jgm/4229/2 "2022-07-12T01:15:54Z")
My thoughts… ## Lot’s of things to like: 1. Simpler and richer inline syntax. The [precedence rules](https://htmlpreview.github.io/?https://github.com/jgm/djot/blob/master/doc/syntax.html#precedence). 2. Nixing indented code blocks. Yea! 🎉 3. Footnotes. Yea! 🎉 4. No magic whitespace thresholds. 🎉🎉 5. Leading and trailing pipes in Pipe Tables are required. 6. Official support for custom containers / divs 🚀 ## The things I’m not so sure of, feels to much like writing code: - The elimination of shortcut link syntax. I think this makes things harder for humans just to make them easier for machines. I thought the point of machines was the reverse. I guess am not in favor of [Rationales](https://github.com/jgm/djot#rationale) #1 and #2. - The `{_` and `_}` syntax. But maybe the use cases for this are so corner that it’s ok that it’s not very natural. ## I don’t yet grok the impact of _Rationale #6_ Rationale #6: > Parsers should not be forced to recognize unicode character classes, HTML tags, or entities, or perform unicode case folding. That adds a lot of complexity. I suspect the case-sensitivity will be counterintuitive to most people and will result in a lot of broken links. My understanding is that djot does this purely for performance reasons. This to me is another case of favoring the machine over the human. ## Manual line wrapping: The decision I question most, for Markdown, djot and others > 🚩 To be clear, this criticism is NOT djot specific. But if we are going to talk about a replacement for Markdown, it must include a reevaluation of any assumptions or decisions that might have been a mistake. The unintended consequences to a syntax precipitated by support for manual line wrapping are far ranging and unintuitive, consequences I believe resulting in the well-known non-programmer dislike of Markdown and other “writer-oriented” markup syntaxes. You might think that manually wrapping lines is entirely optional. Yes it is, but paying the costs of that syntax support is not. _Rationale #7:_ > The syntax should be friendly to hard-wrapping: hard-wrapping a paragraph should not lead to different interpretations. Before I get into the costs, I want to question the justification: > why hard-wrap at all? Answer: so that your document is readable just as it is, without conversion to HTML and without special editor modes that soft-wrap long lines Is soft wrapping truly a “special editor mode”? If it is, it seems like another case where we’re forgetting that machines should be serving humans. There are plenty of editors that soft wrap, and many of them soft wrap intelligently, maintaining the indentation of the preceding line. And for any editor that is going to support syntax highlighting, it can just as easily support smart soft wrapping and indentation that reflects the syntax, e.g. dynamically indenting to align list item content past the list marker. ### Some of the many costs (to humans) imposed by manual line wrapping support - You need to use a special character to force a line break, e.g. placing a `\` at the end of each line of verse. - Writing block quotes or list items with manual line wrapping is a real chore. No one should have to enter so many `>` chars or have to manually indent each wrapped line of a list item. That should be the machine’s job, and in fact many editors do automatic indentation of soft-wrapped lines. - Editing existing manually wrapped text becomes a chore. Inserting even a word requires manually rewrapping all of a paragraph. It’s even worse for block quotes, as you have to remove and reinsert `>` as you manually hard wrap. Sure, you can choose not to rewrap, but then why the manual wrapping in the first place? - Supporting manual line wrapping results in syntax complications all over the place. For example, you are forced to choose between CommonMark’s complex rules for starting a list item after a paragraph without a blank line, or always requiring a blank line as djot does. Forcing blank lines seems the simple solution, but it’s very natural for many people to not use them, even feeling “wrong” to be forced to use them when unnecessary: - Complex and unnatural behavior for block continuation: - Alway using blank lines isn’t natural or often desirable, as explained within this example: There other costs. The ones above are off the top of my head. But in essence: 🌶 _Manual line breaks and its unintended consequences to me are Markdown’s greatest Achilles heal. It unnecessarily took us backward in time, back to dumb typewriters, where you have to manual slide the print head at the end of each line, where editing becomes a nightmare. Just because we want to ditch the proprietary or human-unfriendly storage formats of word processors doesn’t mean we have to go back to typewriters._ --- _[View the full topic](https://talk.commonmark.org/t/djot-a-light-markup-language-by-jgm/4229)._