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].
CommonMark spec[1] is laaarge and not formal (no grammar).
StrictMark has block-level[2] and inline[3] grammars, 100+ and 200+ lines of Ragel code respectively. May parse with regexes too, and results will be identical.
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.
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.
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.
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.
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.
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.
It depends on what ecosystem you exist in whether reStructuredText or AsciiDoc is more common. reStructuredText came from Python and is vastly more common there, AsciiDoc came from Ruby and is vastly more common there. Me, I’ve seen a lot more reStructuredText than AsciiDoc. Also having studied lightweight markup languages closely (and designed and used my own for the last five or six years, which I’ve almost finished implementing at last!), I think AsciiDoc has more serious design problems than reStructuredText. And without doubt it’s uglier.
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.
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.
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.
As prior art, see also djot (~2023), from the pandoc folks: carefully crafted as more well-formed than markdown. Notwithstanding the provenance and engineering, it had minimal uptake.
This is not simpler or nicer (per the current submission title) or better or cleaner (per the linked article). Well, it may be simpler in some regards if it lacks Markdown’s HTML basis (source of all kinds of problems but also of its popularity). Oh, and definitely simpler in being limited to two levels of headings (read: document title plus one level of heading). But nicer, better, cleaner? It seems to be determinedly different in a variety of capricious ways that are not obviously superior, and are sometimes obviously inferior. And only supporting one level of heading after the document title is… a choice; and not one I’m willing to consider better or cleaner.
—⁂—
Code blocks are indented by six spaces. Oddly specific. Four spaces or one tab I could understand, even two or eight spaces have some precedent, but six spaces?
Combining that with treating “### ” as special… very odd.
—⁂—
Link syntax is possibly even worse than Markdown’s.
Now Markdown’s is terrible: people mix up the square brackets and parentheses frequently, the fact that the href is next to the delimited text rather than inside (e.g. [text <href>] or [text|href]) is dubious, and it uses as its closing delimiter the right parenthesis which doesn’t get escaped in URLs <https://url.spec.whatwg.org/#url-code-points> so that you have to add an extra step after normal URL serialisation, { '(' → %28, ')' → %29 }, for general correctness.
But Shrimple’s? The idea of merging hrefs with footnotes is definitely appealing, but the way it’s been done is hard to read and quite unmanageable. The link is essentially delimited by a "-> " prefix and a "[N]" suffix. Tough to read, though syntax highlighting may make it more bearable. But really, paired delimiters are generally safer. In Markdown, it would have been a "[" prefix and a "][N]" suffix, and that would have been nicer.
Then the URLs (as text, not linked) remain at the end of the document, devoid of context.
And you can only use numbers, not names. And to be frank, inline hrefs are better a significant fraction of the time.
Footnotes are a bad idea in general: you have to go all the way to the end of the document to resolve them, then find your way back. By contrast, in languages like Markdown and reStructuredText you can define your links closer to where they’re used, if you wish.
reStructuredText_ lets you link a single word with a trailing underscore.
Multi-word link targets need `backtick delimition`_.
In either form, double the underscore for an anonymous link__,
which you can place after the paragraph.
That might sometimes be neater than using an `inline reference <https://example.com>`_.
__ https://example.com/
.. _reStructuredText: https://docutils.sourceforge.io/rst.html
.. _backtick delimition: https://docutils.sourceforge.io/docs/user/rst/quickref.html#hyperlink-targets
I also think that notes sources should be spanned: mark which words the footnote applies to. But that sort of thing is going beyond what Markdown covers.
(Content-wise: looking at the footnotes, I see two orphaned footnotes, and one of them seems to have bad HTML escaping done to it, > becomes &rt; which is invalid; where I would have expected that -> to become a link.)
—⁂—
Lists: requiring two-space indentation is bizarre. For bullets, it can be nice to match four-space block indentation, and that’s how I’ve tended to write things in my own lightweight markup language (LML), but then for numbers you want one or zero spaces to keep up that concept. In the end, it’s just… why?
> Subsequent items may be numbered normally (unlike Markdown, where they all have to be "1").
That’s flat-out wrong about Markdown.
> Numbers don't have to be consequtive, but they will be normalized to be consequtive. It just werks!
Yuck, yuck, yuck. That’s what Markdown does, and I hate it. If I wrote 44, I meant 44. If you really want to, have tooling that detects sequence breaks and warns “did you actually mean 44?”, but changing what the user clearly wrote is nasty.
—⁂—
Parse and render dictionaries: seems a very specific feature that is unlikely to compose well. The basic concept can definitely be useful, but I don’t think it’s exposed well.
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...
How does it compare to CommonMark, which I think was the first formally specified Markdown dialect?
CommonMark spec[1] is laaarge and not formal (no grammar). StrictMark has block-level[2] and inline[3] grammars, 100+ and 200+ lines of Ragel code respectively. May parse with regexes too, and results will be identical.
[1]: https://spec.commonmark.org/0.31.2/
[2]: https://github.com/gritzko/beagle/blob/main/dog/tok/MKDTB.c....
[3]: https://github.com/gritzko/beagle/blob/main/dog/tok/MKDT.c.r...
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.
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.
Triple backticks also let you specify the syntax very conveniently.
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.
I wish HN supported triple backticks.
> 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!
Lol, I have personally written docs down to at least h4-5
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.
> I sort of lament the use of lines under headings, as they look visually better for human readers of Markdown
Maybe I am spoiled but I rarely read markdown directly. As a user of vscode I do ctrl + shift + v on a markdown file and read the rendered version.
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_...
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.
It depends on what ecosystem you exist in whether reStructuredText or AsciiDoc is more common. reStructuredText came from Python and is vastly more common there, AsciiDoc came from Ruby and is vastly more common there. Me, I’ve seen a lot more reStructuredText than AsciiDoc. Also having studied lightweight markup languages closely (and designed and used my own for the last five or six years, which I’ve almost finished implementing at last!), I think AsciiDoc has more serious design problems than reStructuredText. And without doubt it’s uglier.
Why does Ruby make Asciidoctor horrible to work with?
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.
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.
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.
I like that urls are footnotes and can be in any order. That is very, very nice
As prior art, see also djot (~2023), from the pandoc folks: carefully crafted as more well-formed than markdown. Notwithstanding the provenance and engineering, it had minimal uptake.
- https://djot.net
- https://github.com/jgm/djot
Interesting but need a side-by-side comparison to Markdown.
This is where my mind went: https://xkcd.com/927/
why are we reinventing the wheel? markdown works fine.
See also https://minimal.app/mnml-formatting.html, with code blocks recently added
It sounds like that’s an input mode (which maps immediately to rich structures), not a markup language.
> Headers are allowed to be of two level types
Come on, two levels ain't enough for anything serious. Also, the notes feature is not rendering any differently.
This is not simpler or nicer (per the current submission title) or better or cleaner (per the linked article). Well, it may be simpler in some regards if it lacks Markdown’s HTML basis (source of all kinds of problems but also of its popularity). Oh, and definitely simpler in being limited to two levels of headings (read: document title plus one level of heading). But nicer, better, cleaner? It seems to be determinedly different in a variety of capricious ways that are not obviously superior, and are sometimes obviously inferior. And only supporting one level of heading after the document title is… a choice; and not one I’m willing to consider better or cleaner.
—⁂—
Code blocks are indented by six spaces. Oddly specific. Four spaces or one tab I could understand, even two or eight spaces have some precedent, but six spaces?
Combining that with treating “### ” as special… very odd.
—⁂—
Link syntax is possibly even worse than Markdown’s.
Now Markdown’s is terrible: people mix up the square brackets and parentheses frequently, the fact that the href is next to the delimited text rather than inside (e.g. [text <href>] or [text|href]) is dubious, and it uses as its closing delimiter the right parenthesis which doesn’t get escaped in URLs <https://url.spec.whatwg.org/#url-code-points> so that you have to add an extra step after normal URL serialisation, { '(' → %28, ')' → %29 }, for general correctness.
But Shrimple’s? The idea of merging hrefs with footnotes is definitely appealing, but the way it’s been done is hard to read and quite unmanageable. The link is essentially delimited by a "-> " prefix and a "[N]" suffix. Tough to read, though syntax highlighting may make it more bearable. But really, paired delimiters are generally safer. In Markdown, it would have been a "[" prefix and a "][N]" suffix, and that would have been nicer.
Then the URLs (as text, not linked) remain at the end of the document, devoid of context.
And you can only use numbers, not names. And to be frank, inline hrefs are better a significant fraction of the time.
Footnotes are a bad idea in general: you have to go all the way to the end of the document to resolve them, then find your way back. By contrast, in languages like Markdown and reStructuredText you can define your links closer to where they’re used, if you wish.
I also think that notes sources should be spanned: mark which words the footnote applies to. But that sort of thing is going beyond what Markdown covers.(Content-wise: looking at the footnotes, I see two orphaned footnotes, and one of them seems to have bad HTML escaping done to it, > becomes &rt; which is invalid; where I would have expected that -> to become a link.)
—⁂—
Lists: requiring two-space indentation is bizarre. For bullets, it can be nice to match four-space block indentation, and that’s how I’ve tended to write things in my own lightweight markup language (LML), but then for numbers you want one or zero spaces to keep up that concept. In the end, it’s just… why?
> Subsequent items may be numbered normally (unlike Markdown, where they all have to be "1").
That’s flat-out wrong about Markdown.
> Numbers don't have to be consequtive, but they will be normalized to be consequtive. It just werks!
Yuck, yuck, yuck. That’s what Markdown does, and I hate it. If I wrote 44, I meant 44. If you really want to, have tooling that detects sequence breaks and warns “did you actually mean 44?”, but changing what the user clearly wrote is nasty.
—⁂—
Parse and render dictionaries: seems a very specific feature that is unlikely to compose well. The basic concept can definitely be useful, but I don’t think it’s exposed well.
Leave markdown alone. Focus on JS frameworks and harnesses please.
Ah,yes, the world cries out for more JavaScript frameworks.
Indeed
[dead]