[HN Gopher] Djot: A light markup language by the creator of Pand...
       ___________________________________________________________________
        
       Djot: A light markup language by the creator of Pandoc and
       CommonMark
        
       Author : eevilspock
       Score  : 98 points
       Date   : 2022-12-05 16:24 UTC (6 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | tosh wrote:
       | Related: "Beyond Markdown" https://johnmacfarlane.net/beyond-
       | markdown.html
        
       | dschuessler wrote:
       | 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.
       | 
       | 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.
        
         | abathur wrote:
         | Good sign of a persistent yak-shaver :)
        
         | IshKebab wrote:
         | Yeah that stuck out to me as the most objectionable thing at
         | first glance too. Otherwise it looks reasonably sane. I
         | currently use AsciiDoc and it's ok but this looks slightly
         | better I would say.
         | 
         | Both are clearly better than RST.
        
       | mikl wrote:
       | 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.
       | 
       | Shame that the creator of Markdown blocks any efforts to to fix
       | or standardise the format.
        
         | jdelman wrote:
         | CommonMark is the "standardized" version, isn't it?
        
           | anderskaseorg wrote:
           | The creator of the original Markdown requested that the
           | standardized version be renamed to avoid using the word
           | "Markdown".
           | 
           | https://blog.codinghorror.com/standard-markdown-is-now-
           | commo...
        
             | mikl wrote:
             | ...and threatened legal action against anyone using the
             | word "Markdown" in a way he did not approve of.
             | 
             | Jeff Atwood goes out of his way to be courteous to Gruber
             | in this post, but frankly, I think Gruber was being a jerk
             | here, using his claim to the name to tyrannise an open
             | source community that he has otherwise not been involved
             | with in the slightest the last ~17 years.
        
       | civopsec wrote:
       | > 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).
       | 
       | 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.
        
       | 0xbadcafebee wrote:
       | 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.
       | 
       | 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.
        
         | civopsec wrote:
         | Interestingly though in this case it's an amateur programmer
         | (since being a professor of philosophy is his day job).
        
         | nequo wrote:
         | > say, by clicking on the display itself, clicking "Menu ->
         | Layout -> Options" selecting the layout we want, and seeing it
         | displayed immediately
         | 
         | Maybe I am misunderstanding what you are saying. Isn't this the
         | same as LibreOffice Writer and Microsoft Word? What is the
         | existing problem that such an interface would solve?
        
       | adlpz wrote:
       | 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
       | _pretty much_ just what I 'd write in plain text anyways.
       | 
       | The odd newline requirements on lists and blocks, the special
       | syntax for raw HTML and so on makes Djot feel more artificial to
       | me.
        
         | layer8 wrote:
         | What odd newline requirements? I skimmed the syntax reference
         | and couldn't find any.
        
           | trynewideas wrote:
           | Also preferring rST-style list syntax, requiring an empty
           | line between parent and child lists.
           | 
           | So:                 - list         - sublist         -
           | sublist
           | 
           | is valid Markdown but invalid djot, while                 -
           | list                - sublist         - sublist
           | 
           | is valid djot.
        
           | gernb wrote:
           | In markdown                   My favorite number is probably
           | the number         1. It's the smallest natural number that
           | is         > 0. With pencils, though, I prefer a         # 2.
           | 
           | is a paragraph, a list item, a block quote, and a heading (4
           | things). In djot it's just a single paragraph.
           | 
           | If you want it to be 4 things you have to add a newline
           | between each one.
           | 
           | Personally I think djot gets this right.
        
             | layer8 wrote:
             | Ah, thanks. I agree that it makes sense to require an empty
             | line before block elements that typically also require an
             | empty line after.
        
         | qbasic_forever wrote:
         | Exactly, the sublist newline stuff is a total nonstarter for
         | me. Sorry, I guess I'll run a markdown parser that takes an
         | extra second or whatever to run.
        
         | 0cf8612b2e1e wrote:
         | The fact that we cannot standardize on extensions means that
         | markdown feels inadequate for more technical documents. If just
         | a free more restrictions means I can easily add block
         | annotations to everything, I will jump aboard immediately. That
         | it is easier for parser writers is just a perk.
        
           | chungy wrote:
           | I honestly don't get why Markdown became preferred in most
           | projects over AsciiDoc.
        
             | nerdponx wrote:
             | I think this is partly because AsciiDoc has broadly been
             | tied to a single implementation, AsciiDoctor, without a
             | spec, not even a sketch in a blog post like the original
             | Markdown was. It's only recently that AsciiDoc has begun to
             | think of itself as "a markup language" rather than "the
             | markup language used by AsciiDoctor". A spec is apparently
             | WIP.
             | 
             | As for why it never gained the memetic popularity of
             | Markdown that might have led to a different trajectory,
             | that's harder to say. The One True Markdown is
             | fundamentally much simpler than AsciiDoc, and consequently
             | much easier to learn, easier implement in JavaScript for
             | live rendering on the Web, and easier to extend with your
             | own opinionated features. So I think it was easy and
             | attractive for various platforms like Hacker News and
             | Github to support it, and this I think had a snowballing
             | network effect.
             | 
             | Personally I love AsciiDoc and I think it's the future of
             | technical writing and publishing. It's everything I wanted
             | out of reStructuredText but without its fussy, non-
             | composable syntax. However I don't think that future will
             | become reality until a spec is published that is friendly
             | to implementers other than AsciiDoctor.
        
               | chungy wrote:
               | AsciiDoctor is a second implementation that doesn't even
               | fully compatibly implement the original specification.
               | The original AsciiDoc is pretty well-specified, and it's
               | mostly the plaintext markup of stuff that was intended to
               | go to DocBook, with very little surprises from that.
               | 
               | AsciiDoctor pretty much focused on a direct HTML
               | translation and ignored the inconvenient parts. (Some of
               | the inconvenient parts are deprecated syntax that while
               | AsciiDoc's had a replacement for, I've written the old
               | style for ~20 years and when GitHub tries to render a
               | document with AsciiDoctor, oops; sometimes I'll change
               | the document, sometimes I'll decide rendering on GitHub
               | isn't important.)
        
             | markstos wrote:
             | Because people know and like Markdown. It's good enough so
             | they don't go looking for a replacement.
             | 
             | Markdown is used enough that you are going to need to know
             | the syntax. So a competitor doesn't just have to better, it
             | has to have enough additional merits to be worth learning
             | in addition to Markdown.
        
               | nerdponx wrote:
               | AsciiDoctor and Org Mode both have substantial additional
               | merits over Markdown, and have dedicated user bases. The
               | problem nowadays is that of implementation availability.
        
             | wnoise wrote:
             | Have you tried to parse it? Even the Swiss army knife of
             | document formats, pandoc, only supports it as an output
             | format.
        
             | abathur wrote:
             | I suspect a lot of it's inertia from before the choice
             | mattered or was actually reflected on (though I guess there
             | are still plenty of projects changing).
             | 
             | It's easy, most projects can satisfice with it, and people
             | on the projects that can't satisfice with it may not think
             | about markup enough to realize they're painting themselves
             | into a corner until they have a big ballast of existing
             | documentation to cope with?
             | 
             | I've been fumbling around for how to convey signs that a
             | project may need better tools
             | (https://t-ravis.com/post/doc/what_color_is_your_markup/)
             | but it's been slow-going and I'm bearish on how well
             | ~better-practices will spread.
        
         | IshKebab wrote:
         | If you just want the expressiveness of Markdown then that's
         | fine, but this is targeted at the same space as AsciiDoc -
         | writing big documents and even books. It's going to be painful
         | doing that without the ability to add footnotes, cross
         | references, figures, notes, etc. etc.
         | 
         | I mean you can do it - look at all the RFCs for example - but
         | they must have been unpleasant to write and they're certainly
         | unpleasant to read.
        
       | solarkraft wrote:
       | HTML is quite good at what it was invented for. Why is it so out
       | of fashion?
        
         | leephillips wrote:
         | 17^th^ is more pleasant to read and write than 17<sup>th</sup>,
         | for example.
         | 
         | For me, I use Markdown because I can transform it with Pandoc
         | and my own filters to any other kind of document:
         | 
         | https://lee-phillips.org/panflute-gnuplot/
        
         | abathur wrote:
         | Verbosity is the _obvious_ answer, but this past year I
         | stumbled into a conclusion that wasn 't obvious to me before:
         | "semantic" HTML isn't serving authors' needs--it's serving the
         | UA's needs.
         | 
         | I picked at what I mean a little in a post this summer:
         | https://t-ravis.com/post/doc/the_gizmos_role_in_markup/
         | 
         | (I've also made the first post in an unfinished series that
         | will continue to explore these ideas about markup, but a bit
         | less directly:
         | https://t-ravis.com/post/doc/what_color_is_your_markup/)
        
         | Cyberdog wrote:
         | Aside from the sibling answers, Markdown, though originally
         | intended solely for HTML output, is useful for writing other
         | types of documents; I've written an e-book which was eventually
         | destined for PDF format as a series of Markdown files. I could
         | have used HTML instead, but aside from being more difficult to
         | write, Markdown's document orientation solves some problems
         | with that (should the HTML-to-PDF translator handle CSS and
         | evaluate JavaScript? How does it deal with <audio> or <video>
         | tags?) by not making them a possibility in the first place.
         | 
         | Similarly, for things like comments on message boards or blogs,
         | a user can just dump a bunch of text into the text box without
         | knowing the first thing about Markdown and expect it to look
         | more or less like how it was entered, with paragraph breaks and
         | such. If you force these people to use HTML instead, you're
         | forcing them to at least learn and use <p></p> - which is
         | probably simple for those of us reading HN, but I don't
         | consider it a reasonable request for the normies on Reddit.
         | 
         | So, sure, HTML is quite good at what it was invented for, but
         | not everything that involves text input on the internet or
         | elsewhere should be HTML.
        
       | Cyberdog wrote:
       | 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.
       | 
       | 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.
        
       | gernb wrote:
       | 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,
       | 
       | For example:
       | 
       | > Block-level elements can't interrupt paragraphs (or headings),
       | because of goal 7
       | 
       | It then goes on to show they do interrupt paragraphs
       | - this then - this other thing
       | 
       | vs                  - this then        - this other thing
       | 
       | The 2nd is 2 list items but it's just the first with being
       | interrupted by a block-level element.
        
         | chriswarbo wrote:
         | The second example is indented; line-wrapping doesn't introduce
         | indentation, so an indented line cannot be 'interrupting a
         | paragraph'
        
       | joemaller1 wrote:
       | How do you say it?
        
         | jez wrote:
         | The homepage lists the IPA
         | 
         | https://djot.net/
         | 
         | /dZat/
         | 
         | /dZ/ is like both the `j` and `dg` in english judge
         | 
         | /a/ is like the a in father in most American english dialects
         | 
         | /dZat/ is also the complete IPA for the word "jot" (as in "to
         | jot down") in American English
         | 
         | https://en.wiktionary.org/wiki/jot
        
         | dcre wrote:
         | Jot.
        
       ___________________________________________________________________
       (page generated 2022-12-05 23:00 UTC)