Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I like that urls are footnotes and can be in any order. That is very, very nice
  • Having the dashes to make something a headline on another row disconnects meaning. You now have to edit two lines to make one change.

    Same for the code part.

    This might be easier to read but it’s not simpler.

  • Markdown itself introduced that syntax. Though it’s not used nearly as much as it was initially, it’s one of the main features that make it very readable in plain text.
  • Using `-> Title.[1]` for Links looks neat at first. But I often tend to copy links from one Markdown to another. I don't think updating the footnote numbers of *both* Shrimple documents is easier in any way.
  • Well, I like the initiative, but dealing with code blocks looks like hell. You should not mess with the original indentation.

    Also, the markup should at least support tables.

  • The text file looks great, but reading this just makes me think of the XKCD standards comic. Markdown has very few issues, and the remaining ones are so nitpicky that the downsides of having an additional standard are larger than the benefits.

    On the other hand, I am always happy to see progress in the LaTeX alternatives world. That typesetting language has become comically overgrown and I think it's turing complete at this point.

  • > Markdown has very few issues

    Markdown's issue is that it isn't a standard, and many "standard" Markdown implementation default to rending HTML tags without any validation.

  • I thought about writing a markdown variant that is easier to type--every token in grammar should be easily reachable from home row and should not require more than one keypress (e.g. no #). I figured same conclusion as many in comments here: no need to reinvent the wheel. Plus, the aggregate amount of time it'd save me from typing may not exceed the time it would take to implement.
  • Even if this was simpler and better than markdown, I’d purposefully avoid using it because I hate the name so much. A good rule of thumb I just though of: Do not introduce seafood into your branding if you are not a seafood vendor.
  • How does this compare to RST, which also claims to solve specific MD inconveniences?

    In researching for this reply I see that it's joining a somewhat crowded field https://en.wikipedia.org/wiki/Comparison_of_document_markup_...

    by ser0
  • My favourite attempt to improve markdown is djot[0] but I think markdown just has too much inertia and most of its issues aren’t really a problem in practice.

    [0] https://djot.net/

  • RST is pretty much the worst option out there. Your mainstream options are:

    * Markdown. Great for simple stuff. It's going to be awkward if you're writing a book or technical docs or whatever.

    * RestructuredText. Better for more complex documents but the Python code that drives it is abysmal and it's less popular than Asciidoc so there's really no reason to use this.

    * Asciidoc. Definitely a step up from RST but it does have syntax weirdnesses, and the way parsing is done is a messy pile of hacks. Also Asciidoctor is written in Ruby which makes it horrible to work with. But tbh still better than RST due to the low quality of their Python code & docs.

    * Typst. Definitely the best option for complex stuff except that its HTML output support is still experimental. You can make it work nicely with some fiddling and custom CSS though.

    Overall Markdown and Asciidoc are the best options today, or Typst instead of Asciidoc if you are forward-looking.

    This thing just looks like a slight tweak on Markdown which is completely pointless compared to the pain of .. you know, not being supported by any other tools at all.

  • How is it more convenient to add lines under a title than start with a # ? How is it better to limit to h1 and h2 only?
  • I sort of lament the use of lines under headings, as they look visually better for human readers of Markdown, but they're worse in other ways: ambiguous heading levels (quick, which is h2, `===` or `---`?), and less token-efficient.

    For me, the use of indentation over ``` for code blocks is a complete non-starter, though. It's hostile to copy-and-paste.

  • > a better, cleaner Markdown alternative

    What makes it better or cleaner? It isn't explained anywhere on the page. It looks about the same as markdown to me.

  • It looks slightly worse to me. Slightly worse and not even ubiquitous?

    [Edit:] There's h1 and h2, who'd ever need h3? You gotta be kidding me!

  • Indent for code blocks is a non-starter. Can't paste easily, very annoying to type in a web form. Triple backticks is the right thing.
  • I wish HN supported triple backticks.
  • That said, I think it would be better if the closing delimiter was different from the opening one. Yesterday I had an LLM output text where it forgot one of the delimiters, causing all text inside code blocks to actually be outside and vice-versa.
  • Triple backticks also let you specify the syntax very conveniently.
  • Add to that using -> to designate a link with a numbered URL for the actual href (numbered hrefs are already in Markdown), and also needing to indent list items... this is a solution in search of a problem.
  • About five years ago I faced the fact no two Markdown implementations are fully compatible. I made StrictMark[1], which is a backwards-compatible Markdown dialect with a formal grammar (I use Ragel for parser generation btw). Takes 5-10 min with LLMs to make any implementation, cause formal grammar is unchanged. I use it, no one else does, which is not an issue cause it is backwards-compatible. GitHub renders it fine[3].

    Solved my problems. Caused no inconvenience.

    [1]: https://web.archive.org/web/20210130000533/http://doc.replic...

    [2]: https://github.com/gritzko/beagle-journal/blob/main/wiki/Str...

    [3]: https://github.com/gritzko/beagle-journal/blob/main/wiki/Str...

  • Genius! Love it! I'm going to plaster this everywhere!
  • How does it compare to CommonMark, which I think was the first formally specified Markdown dialect?