CommonMark spec, with reference implementations in C and JavaScript

Overview

CommonMark

CommonMark is a rationalized version of Markdown syntax, with a spec and BSD-licensed reference implementations in C and JavaScript.

Try it now!

For more details, see http://commonmark.org.

This repository contains the spec itself, along with tools for running tests against the spec, and for creating HTML and PDF versions of the spec.

The reference implementations live in separate repositories:

There is a list of third-party libraries in a dozen different languages here.

Running tests against the spec

The spec contains over 500 embedded examples which serve as conformance tests. To run the tests using an executable $PROG:

python3 test/spec_tests.py --program $PROG

If you want to extract the raw test data from the spec without actually running the tests, you can do:

python3 test/spec_tests.py --dump-tests

and you'll get all the tests in JSON format.

JavaScript developers may find it more convenient to use the commonmark-spec npm package, which is published from this repository. It exports an array tests of JSON objects with the format

{
  "markdown": "Foo\nBar\n---\n",
  "html": "<h2>Foo\nBar</h2>\n",
  "section": "Setext headings",
  "number": 65
}

The spec

The source of the spec is spec.txt. This is basically a Markdown file, with code examples written in a shorthand form:

```````````````````````````````` example
Markdown source
.
expected HTML output
````````````````````````````````

To build an HTML version of the spec, do make spec.html. To build a PDF version, do make spec.pdf. For both versions, you must have the lua rock lcmark installed: after installing lua and lua rocks, luarocks install lcmark. For the PDF you must also have xelatex installed.

The spec is written from the point of view of the human writer, not the computer reader. It is not an algorithm---an English translation of a computer program---but a declarative description of what counts as a block quote, a code block, and each of the other structural elements that can make up a Markdown document.

Because John Gruber's canonical syntax description leaves many aspects of the syntax undetermined, writing a precise spec requires making a large number of decisions, many of them somewhat arbitrary. In making them, we have appealed to existing conventions and considerations of simplicity, readability, expressive power, and consistency. We have tried to ensure that "normal" documents in the many incompatible existing implementations of Markdown will render, as far as possible, as their authors intended. And we have tried to make the rules for different elements work together harmoniously. In places where different decisions could have been made (for example, the rules governing list indentation), we have explained the rationale for our choices. In a few cases, we have departed slightly from the canonical syntax description, in ways that we think further the goals of Markdown as stated in that description.

For the most part, we have limited ourselves to the basic elements described in Gruber's canonical syntax description, eschewing extensions like footnotes and definition lists. It is important to get the core right before considering such things. However, we have included a visible syntax for line breaks and fenced code blocks.

Differences from original Markdown

There are only a few places where this spec says things that contradict the canonical syntax description:

  • It allows all punctuation symbols to be backslash-escaped, not just the symbols with special meanings in Markdown. We found that it was just too hard to remember which symbols could be escaped.

  • It introduces an alternative syntax for hard line breaks, a backslash at the end of the line, supplementing the two-spaces-at-the-end-of-line rule. This is motivated by persistent complaints about the “invisible” nature of the two-space rule.

  • Link syntax has been made a bit more predictable (in a backwards-compatible way). For example, Markdown.pl allows single quotes around a title in inline links, but not in reference links. This kind of difference is really hard for users to remember, so the spec allows single quotes in both contexts.

  • The rule for HTML blocks differs, though in most real cases it shouldn't make a difference. (See the section on HTML Blocks for details.) The spec's proposal makes it easy to include Markdown inside HTML block-level tags, if you want to, but also allows you to exclude this. It also makes parsing much easier, avoiding expensive backtracking.

  • It does not collapse adjacent bird-track blocks into a single blockquote:

    > this is two
    
    > blockquotes
    
    > this is a single
    >
    > blockquote with two paragraphs
    
  • Rules for content in lists differ in a few respects, though (as with HTML blocks), most lists in existing documents should render as intended. There is some discussion of the choice points and differences in the subsection of List Items entitled Motivation. We think that the spec's proposal does better than any existing implementation in rendering lists the way a human writer or reader would intuitively understand them. (We could give numerous examples of perfectly natural looking lists that nearly every existing implementation flubs up.)

  • Changing bullet characters, or changing from bullets to numbers or vice versa, starts a new list. We think that is almost always going to be the writer's intent.

  • The number that begins an ordered list item may be followed by either . or ). Changing the delimiter style starts a new list.

  • The start number of an ordered list is significant.

  • Fenced code blocks are supported, delimited by either backticks (```) or tildes (~~~).

Contributing

There is a forum for discussing CommonMark; you should use it instead of github issues for questions and possibly open-ended discussions. Use the github issue tracker only for simple, clear, actionable issues.

Authors

The spec was written by John MacFarlane, drawing on

  • his experience writing and maintaining Markdown implementations in several languages, including the first Markdown parser not based on regular expression substitutions (pandoc) and the first markdown parsers based on PEG grammars (peg-markdown, lunamark)
  • a detailed examination of the differences between existing Markdown implementations using BabelMark 2, and
  • extensive discussions with David Greenspan, Jeff Atwood, Vicent Marti, Neil Williams, and Benjamin Dumke-von der Ehe.

Since the first announcement, many people have contributed ideas. Kārlis Gaņģis was especially helpful in refining the rules for emphasis, strong emphasis, links, and images.

Issues
  • Pathological input can cause a segfault...

    Pathological input can cause a segfault...

    ...presumably by stack overflow (recursion).

    python -c 'print "*a **a " * 100000; print " a** a*" * 100000' | ./cmark
    

    See http://talk.commonmark.org/t/should-the-spec-address-nesting-limits/602 for a related discussion. Leaving aside the question of what, if anything, the spec should say, cmark definitely needs to be modified so that it will handle this input (and other pathological cases) more gracefully. A limit to emph nesting depth would be one way.

    opened by jgm 41
  • Don't Call It Standard Markdown

    Don't Call It Standard Markdown

    Y'all didn't create Markdown and don't particularly have the right to create a "standard" based on it against the wishes of the original author.

    From the license:

    Neither the name “Markdown” nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

    It seems like you did both. Please provide proof of your written permission or consider a new name.

    opened by stevekinney 38
  • Broken indentation in ordered lists indented by 2 spaces

    Broken indentation in ordered lists indented by 2 spaces

    I'm rendering the following code via markdown-it, which should be CommonMark compliant:

    - Foo
      - Bar
        - Baz
          - Qux
    
    1. Foo
      1. Bar
        1. Baz
          1. Qux
    

    And this is the result:

    Screen Shot 2019-07-07 at 21 17 31

    IMHO if unordered lists indented with 2 spaces are supported than ordered lists indented with 2 spaces should be supported too, right?

    opened by fabiospampinato 35
  • Buggy url encoder in commonmark.js

    Buggy url encoder in commonmark.js

    https://github.com/jgm/CommonMark/blob/master/js/lib/inlines.js#L190

    It can throw exception:

    1. on invalid url format
    2. on broken unicode sequence
    3. on some valid urls

    Also it can produce non-standard urls for international domain names.

    I plan migrate to https://github.com/defunctzombie/node-url instead of home-made magical kludges. That can also require to fix some tests content (didn't checked yet).

    Normalization is not mandatory, but it's more simple to use well-tested solution instead of describing all edge cases and writing correct encoder.

    For reference:

    • https://en.wikipedia.org/wiki/URL_normalization
    JS 
    opened by puzrin 34
  • "HTML blocks" section vague, doesn't match parsers

    The HTML blocks section provides the definition of an HTML block tag. Later on, the following example is presented:

    <div class
    foo
    

    The example header says: "An incomplete HTML block tag may also start an HTML block"

    The problem with this is: what's an incomplete HTML block tag? There's no definition that allows me to parse the syntax for such a tag. Does a single < count as an incomplete tag? According to the [current] rules of HTML block parsing, the above would render as <p>&lt;div class\nfoo</p>.

    But even if we do provide a definition, what's the point in allowing incomplete tags? Could that be useful sometimes? And, more importantly, if an incomplete block tag can start a block, why can't an incomplete comment, or an incomplete CDATA section, or an incomplete processing instruction start a block?

    <!--
    
    Markdown here
    
    -->
    
    <![CDATA[ some data
    
    spec 
    opened by mildsunrise 26
  • You guys failed to made the list sane

    You guys failed to made the list sane

    This

    1. asd
    2. qwe
    3. 345
    

    Produces this

    <ol>
    <li>asd</li>
    <li>qwe</li>
    <li>345</li>
    </ol>
    

    And this

    1. asd
    2. qwe
    
    1. 345
    

    Produces this

    <ol>
    <li><p>asd</p></li>
    <li><p>qwe</p></li>
    <li><p>345</p></li>
    </ol>
    

    This makes completely no sense, totally unintuitive and useless and contrary to the intention of everyone in their right mind. Who on earth needs to wrap their list items in paragraphs and who one earth would try to achieve this by inserting a blank line at random place in the list?

    opened by ghost 21
  • Enfastenate the C Parsenator

    Enfastenate the C Parsenator

    Hey John,

    As promised, this is the WIP PR of the optimization work I intend to commit to the parser. I'm hoping we can have some quiet time talking about parsers and specs, and hopefully away from the flamewars and other political stuff going around here. Please feel free to read the following optimization notes when you have some time to spare and share with me your feedback. This parser is your (amazing) work, so the only thing I want is going through these changes with you to make sure they make sense to you and are in the spirit of what you're trying to accomplish with the C implementation. Wall of text follows.

    For this first iteration, all the parsing logic has been left unchanged (to the extent it was possible when refactoring). The only thing I've done is going through every line in the code base that was allocating memory, and changed it so it didn't allocate memory.

    The results of this iteration are quite good:

    screen shot 2014-09-04 at 8 22 43 pm

    Here are some notes on the changes I wanted to discuss:

    • bstring is gone because it was "memory allocation as a service". As a reminder, this is what the stack profiler showed on the old implementation

      samples  %        image name               symbol name
      2405     20.4820  libc-2.19.so             __memmove_ssse3_back
      1237     10.5348  libc-2.19.so             vfprintf
      893       7.6052  libc-2.19.so             _int_malloc
      794       6.7621  no-vmlinux               /no-vmlinux
      758       6.4555  libc-2.19.so             _int_free
      594       5.0588  libc-2.19.so             fgetc
      560       4.7692  libc-2.19.so             _IO_strn_overflow
      544       4.6329  libc-2.19.so             _IO_default_xsputn
      518       4.4115  libc-2.19.so             malloc
      287       2.4442  stmd                     bgets
      233       1.9843  stmd                     binchr
      206       1.7544  stmd                     bformata
      199       1.6948  stmd                     bdetab
      159       1.3541  libc-2.19.so             strlen
      153       1.3030  libc-2.19.so             malloc_consolidate
      

      Over 30% of the time was spent allocating memory (the memmove call is, in fact, sourced from malloc -- it is moving the strings around after reallocations).

      In order to cut down on the string allocations I did two things:

      1. Replace bstring with strbuf (buffer.h), the buffer api we use in libgit2 which tries very hard not to allocate memory if not strictly necessary. strbufs are stack allocated, so they are embedded as-is inside a struct, or passed as a pointer from a stack value.
      2. Replace all the intermediate strings with a chunk data structure (chunk.h). Chunks are pointers to substrings that reuse the memory of other strings. They are not null-terminated, but they have a len argument. All the parsing code has been changed accordingly to work on length-delimited instead of null-terminated strings (this is the main reason the diff size has ballooned up so much).

      After these two changes, we only "grow" strings in one main place when parsing: the string_content buffer inside the block struct, where we insert the lines for the current block as they are fed into the parser. All the other parsing happens on pointers to that content buffer, without allocating temporary strings from it.

      In the same vein, the html output renderer has been rewritten to only grow one string, the strbuf you initially pass to it. Because of the nature of the AST, all the HTML can be written directly to that output buffer without requiring any intermediate strings to hold partial results. It is a quite elegant design.

    • The main bottleneck in the parser now was the HTML escaping routines. I took the easy route and cherry-picked code from Houdini The Escapist (the delightfully named escaping library I wrote for GitHub). This fixed the performance bottleneck (Lookup tables are fast indeed), but threw me down a rabbithole regarding our existing spec which I very much wanted to discuss with you.

      From my point of view, there are parts of the spec that are not doing the right thing when it comes to escaping (and believe me, I spent way more time than I'd like trying to figure out how to safely escape content for the web).

      The current parser has one HTML escaping function, with two modes: HTML escaping that affects entities, and HTML escaping that doesn't. I don't think this is correct. According to all RFCs and standards, URIs (and hence URLs) need to be scaped in a specific way in order to be valid. Some immediate examples from spec.txt come to mind.

      1. [αγω] results in <a href="/φου">αγω</a>. This is not a valid URL, this is an IRI. Some Web browsers can access the kind of link, but the spec very clearly defines that characters outside of the ASCII range need to be encoded for an URL to be valid. <a href="/%CF%86%CE%BF%CF%85">αγω</a> would be a valid URL.
      2. [link](</my uri>) results in <a href="/my uri">link</a>. Again, this is not a valid URL. <a href="/my%20uri">link</a> is the URL that all standard conforming browsers can actually parse.
      3. In [link]("title"), the parser identifies "title" as the URL, and yet this is its output: <a href="&quot;title&quot;">link</a>. Although all the characters in this "url" are valid, & and ; have reserved meanings int the URL spec. The right escaping sequence would be to URL-encode the quotes, not to escape them into entities, because entities don't belong in an url. <a href="%22title%22">link</a>

      Basically, the question I'm raising here is: Should the Markdown parser be responsible of generating valid URLs on the outputted HTML?. I personally believe this should be the case. The current spec has several examples with URLs that are not valid. Do you think this should be changed?

    • Moving on from escaping hell, I went into the dephts of UTF8. The existing UTF8 routines had performance issues. I replaced them with code from the utf8proc library (moved to utf8.c), which is extremely well battletested and openly licensed. The result is faster, and I believe, easier to comprehend when reading the source.

      Two functional changes regarding UTF8:

      1. I removed the invalid codepoint error handling. The previous iteration would replace invalid codepoints with the default "unknown codepoint" character and print a noisy message to stderr. It occurs to me that simply outputting the "unknown codepoint" char is simply the right thing to do, and after doing so, there's no point on warning the user or returning error codes, specially because there's only one way to recover from this error: to output an invalid codepoint char. Which is what we're doing. This greatly simplified the error handling of the library. Do you agree this is a reasonable change?
      2. Early during this iteration, I replaced the UTF-8 aware detab function with a simpler one that was not UTF8 aware but was using the new strbuf (that would allow me to boostrap the whole parsing process into strbufs more easily). I added a note to come back and rewrite the function to be UTF8 aware. However, several days later I noticed that no tests in the spec fail without an UTF8 aware detab. This makes sense, because the only places where detabbing is significant in the spec is at the beginning of each line, and the UTF8 detab obviously doesn't affect beginning of lines, as its behavior only goes into effect when detabbing after a multi-point UTF8 character. Does this make sense? Can you think of any counter-examples that make UTF8-aware detabbing a necessity?
    • As a general cleanup, I removed the getopt.c file (which is not used anywhere), and the codefold.c file, which is not used either (it looked like the output of a previous iteration of the gencodepoint script.

    • To wrap up, I renamed several structures and enums from the main header. I was hesitant to do this is at first, because your naming made for very readable code, but all the identifiers were way too short to be used in a public-facing header. Things like the link enum, for instance, would cause the library to simply stop compiling when included next to stdlib.h, as it would redefine the int link() syscall. Likewise for code, document, inl and other very short names that could and were clobbering local variables from other programs.

    What is next? Here's a small list of projects I'd like to tackle next:

    • I'm going to fix the escaping/entities issues once I can get your feedback on what should be the right behavior for these things.
    • I'm going to remove all the mallocs in the AST parser and replace them with a slab allocator. This is gonna be a seriously simple and free speed win because all the nodes in the AST have the same alloc size!
    • I'm going to replace the insanely complex uthash with something much simpler because hash lookups are most definitely not a bottleneck. In fact, they rarely happen.
    • I'm going to cleanup and define the external APIs so we can try building this as an external library.
    • I'm going to run the parser through a corpus of millions of Markdown documents I'm gathering, and valgrind the fuck out of it to make sure it cannot leak or break.

    After all that, I really believe we can end up with a library that is both faster than Sundown, more powerful (fuck yes, ASTs), more accurate when parsing, and more approachable to modify.

    I'll leave this PR open as I iterate on this. Thanks for taking the time to read my notes and my code. Please let me know what do you like from here, what should we change and what should we ditch.

    Regards, vmg

    opened by vmg 20
  • Feature Request: Source maps

    Feature Request: Source maps

    It would be great to click in the preview pane in a Markdown editor & select the piece of source Markdown that rendered to that text.

    Can you add an option to generate source maps so that editors can support this?

    This is also necessary for synchronized scrolling.

    /cc @am11 @madskristensen

    opened by SLaks 16
  • Test runner needs proper HTML normalization

    Test runner needs proper HTML normalization

    The spec says (section "Entities"):

    With the goal of making this standard as HTML-agnostic as possible, all valid HTML entities in any context are recognized as such and converted into unicode characters before they are stored in the AST.

    [...]

    Conforming implementations that target HTML don’t need to generate entities for all the valid named entities that exist, with the exception of " ("), & (&), < (<) and > (>), which always need to be written as entities for security reasons.

    From the statement above I understand that when the parser finds an entity, it must unescape it and store the equivalent character in the AST, and is required to reescape the symbols "&<> as entities when rendering. My parser does this.

    While these symbols are required to be reescaped, it says nothing about other entities, so I understand that a parser rendering this:

    Foo &egrave; á &COPY; bar
    

    As any of the following:

    <p>Foo &egrave; &aacute; &copy; bar</p>
    <p>Foo &egrave; á &copy; bar</p>
    <p>Foo &EGRAVE; á &COPY; bar</p>
    <p>Foo &EGRAVE &aacute; &copy; bar</p>
    

    Is fine and should be accepted as it's equivalent HTML. However, this is not the case with the test runner. It doesn't normalize entities; not even the basic ones like &#39 (single quote), &#x27; (backslash) or &grave (backtick). So my parser, which is based on Houdini and escapes single quotes, fails some tests.

    ✘ Example 422 (line 5755)
    === markdown ===============
    <a href="hi'> <a href=hi'>
    === expected ===============
    <p>&lt;a href=&quot;hi'&gt; &lt;a href=hi'&gt;</p>
    === got ====================
    <p>&lt;a href=&quot;hi'&gt; &lt;a href=hi&#39;&gt;</p>
    

    The funny thing is, it tries to (and successfully) normalizes the first single quote (which the parser returned as &#39;), but it still leaves the next one as an entity, and the test fails.

    This should be a bug in the tidy function, maybe?

    opened by mildsunrise 15
  • is [a](<b)c> supposed to be an inline link?

    is [a]( supposed to be an inline link?

    See https://talk.commonmark.org/t/why-is-a-b-c-not-parsed-as-an-inline-link/2436.

    It is obvious that both [a](<b)c and [a](<b)c>) are inline links, but why is [a](<b)c> not parsed as inline link followed by c> in most (or even all?) CommonMark-conformant parsers?

    http://johnmacfarlane.net/babelmark2/?normalize=1&text=%5Ba%5D(%3Cb)c%3E

    IMHO, <b is a valid "link destination", therefore [a](<b)c> should be parsed as inline link.

    And if that's not desired, the spec should be changed accordingly.

    opened by mgeier 14
  • API documentation

    API documentation

    We should have a plan for generating API documentation. Would it make sense to use doxygen? I haven't used it myself, but it purports to generate HTML and man page documentation from comments in the source.

    opened by jgm 14
  • Remove restrictive limitation on inline comments

    Remove restrictive limitation on inline comments

    • This limitation is not imposed by block comments
    • This limitation is not imposed by HTML
    • This limitation is not expected to be depended on by authors

    Closes GH-712.

    opened by wooorm 0
  • (Intentional?) inconsistency between 4.6 block HTML and 6.6 raw HTML comments

    (Intentional?) inconsistency between 4.6 block HTML and 6.6 raw HTML comments

    The block HTML algorithm here allows <!-->, <!--->, etc, as comments. These comments are also fine by the HTML parser (13.2.5.44, case for U+002D). (note there are a couple of cases such as <!> and <!-> which HTML also allows but sees as parse errors, I am not talking about these).

    The “inline” algorithm here does not allow <!--> or <!--->. They look a lot like comments, so I don’t really expect people to depend on these characters to be text. And it’s inconsistent with blocks. Can we change the spec to allow them?

    I can do the work

    opened by wooorm 5
  • Leave the content of `<code>` and related HTML elements untouched by CommonMark parser

    Leave the content of `` and related HTML elements untouched by CommonMark parser

    Hello,

    Recently I discovered that CommonMark allows Markdown parsing within <code> blocks!

    So if user had something like <code>**bold**</code> in their markdown content (which is analogous to Markdown `**bold**`), the CommonMark parser would parse those asterisks in there.

    This can be reproduced at least with this CommonMark dingus

    image

    Can the spec be updated so that the content inside <code> (and also <kbd>, <samp> and <var>) also be treated verbatim like that done for the <pre> element?

    • <code> element

      displays its contents styled in a fashion intended to indicate that the text is a short fragment of computer code

      Now, if that short fragment happens to have Markdown markup characters, we don't want a markdown parser to render those as Markdown!

    • <kbd> element

      represents a span of inline text denoting textual user input from a keyboard, voice input, or any other text entry device

      The textual user input on the keyboard can contain asterisks, underscores and square-brackets too. We wouldn't want a Markdown parser to interpret those!

    • <samp> element

      used to enclose inline text which represents sample (or quoted) output from a computer program.

      What if the computer program is outputting Markdown text.. we want this element to show exactly what the computer program's output was; we won't want a Markdown parser to corrupt the sample of the output which the user is trying to preserve in a <samp> element.

    • <var> element

      represents the name of a variable in a mathematical expression or a programming context

      Mathematical expressions easily contain asterisks. We don't want the Markdown parsers to touch these elements either!

    /cc: @jmooring

    opened by kaushalmodi 12
  • code block \w filename

    code block \w filename

    hi 👋

    today i saw another documentation today elsewhere and found this: image

    I struck me that many quite often want to present a code example and giving it an example filename along with it. We sometimes see things such as:

    ```js 
    // functions/_middleware.js
    
    const errorHanddler = ...
    ```
    

    i just thought that it would be a good idea if there was a spec'ed way of giving it an example filename:

    ```js filename=functions/_middleware.js
    const errorHanddler = ...
    ```
    
    opened by jimmywarting 3
  • Parse link references without knowledge of definitions

    Parse link references without knowledge of definitions

    Heya, I would like to understand the rationale behind https://spec.commonmark.org/0.30/#example-568

    [foo][bar][baz]
    
    [baz]: /url
    
    <p>[foo]<a href="/url">bar</a></p>
    

    This enforces on both users and parsers that [foo][bar][baz] cannot be "understood" in isolation, but only after all definitions within the document have been identified.

    Particularly for parsers (such as markdown-it and remark), this necessitates a bunch of extra complexity to run a "pre-parse", before one can actually parse the document in full. In turn, it precludes any kind of streamed or incremental parsing, or to write a good regex based syntax highlighter (such as TextMate grammars)

    I feel the output of this example should be:

    <p>[foo][bar]<a href="/url">baz</a></p>
    

    or even just

    <p><a href="/url">baz</a></p>
    

    i.e.

    1. There would be a full parse, during which both [foo][bar] and [baz] are captured as link references in the AST.
    2. During this parse all definitions are also captured
    3. On conversion to HTML, when encountering the [foo][bar] link reference, with no matched definition, it would be output in its raw (encoded) format, or even just omitted.

    Is there any rationale to Example 568 that I am missing?


    In fact, the syntax highlighting, here on GitHub, demonstrates exactly the problem, in that it cannot "work out" what is a link reference, and incorrectly highlights [foo]:

    image
    opened by chrisjsewell 3
Releases(0.30)
  • 0.30(Jun 20, 2021)

    • Add note clarifying that not every feature of HTML examples is normative (#672).
    • Move "Backslash escapes" and "Character references" to "Preliminaries" (#600). It was confusing having them in the "Inline" section, since they also affect some block contexts (e.g. reference link definitions).
    • Clarify wording in spec for character groups (#618, Titus Wormer, with Johel Ernesto Guerror Peña).
      • Remove line tabulation, form feed from whitespace
      • Rename newline to line feed or line ending
      • Reword spec to be more explicit about whitespace
      • Rename Punctuation to Unicode punctuation
      • Reword description of line breaks
      • Link unicode punctuation
      • Clarify link whitespace by describing "link information"
      • Clarify link destination and title
    • Add definition of ASCII control characters (#603, Titus Wormer).
    • Fix wording in start condition of type 7 HTML (#665, Titus Wormer).
    • Add textarea to list of literal HTML block tags (#657). Like script, style, and pre, textarea blocks can contain blank lines without the contents being interpret as commonmark.
    • Add textarea to more cases (#667, Titus Wormer).
    • Remove superfluous restrictions on declarations (#620, Titus Wormer). HTML declarations need not be limited to all capital ASCII letters.
    • Add inline link examples with empty link text (#636, jsteuer).
    • Remove outdated restriction on list item (#627, Johel Ernesto Guerrero Peña). This is a holdover from the days when two blank lines broke out of a list.
    • Add example with unbalanced parens in link destination.
    • Clarify that new blocks are added to container blocks. (#598, Jay Weisskopf).
    • Clarify language for backtick code spans (#589, Johel Ernesto Guerrero Peña).
    • Fix link text grouping sample (#584, Ashe Connor, Johel Ernesto Guerrero Peña).
    • Fix misleading text for full reference link (#581). There is no "first link label" here, just a link text.
    • Use better example to test unicode case fold for reference links (#582). The earlier test could be passed by implementations that just uppercase.
    • Test new entity length constraints (#575, Miha Zupan).
    • normalize.py: replace cgi.escape with html.escape (#656, Christopher Fujino).
    • tools/make_spec.lua:
      • Fix unqualified calls to node_append_child.
      • Remove extraneous href attribute on headings (#625, Christoph Päper).
      • Properly handle cross-refs (#578). Previously it broke in a few cases, e.g. with soft breaks.
      • Use unsafe mode so HTML isn't filtered out.
      • Changes for compatibility with lua 5.3's new number type.
    • CSS and HTML improvements in HTML version of spec (#639, #641, 642, Andrei Korzhyts).
    • Revise emphasis parsing algorithm description in light of commonmark/cmark#383.
    • Add documentation of the npm package to README.md (thanks to Shawn Erquhart).
    • Fix anchor definition for 'end condition'.
    • Remove duplicate example (#660, Titus Wormer).
    • Remove duplicate links in spec (#655, Levi Gruspe).
    • Various typo fixes (#632, Scott Abbey; #623, Anthony Fok; #601, #617, #659, Titus Wormer).
    Source code(tar.gz)
    Source code(zip)
  • 0.29(Apr 8, 2019)

    [0.29]

    • Clarify that entities can't be used to indicate structure (#474). For example, you can't use &#42; instead of * for a bullet list, or &#10; to create a new paragraph.

    • Limit numerical entities to 6 hex or 7 decimal digits (#487). This is all that is needed given the upper bound on unicode code points.

    • Specify dropping of initial/final whitespace in setext heading content (#461).

    • Add example with a reference link definition where the reference is never used (#454).

    • Add example with setext header after reference link defs (#395).

    • Clarify that script, pre, style close tags can begin an HTML block (#517).

    • Remove meta from list of block tags in start condition #6 of HTML blocks (#527). meta tags are used in some inline contexts (though this isn't valid HTML5), e.g. in schema.org.

    • Disallow newlines inside of unquoted attributes (#507, Shyouhei Urabe) as per HTML spec: https://html.spec.whatwg.org/multipage/syntax.html#unquoted.

    • Remove vestigial restriction in list item spec (#543). The "not separated by more than one blank line" was a left-over from an earlier version of the spec in which two blank lines ended a list.

    • Fix tests where list items are indented 4+ spaces (#497). The tests did not accord with the spec here; these lines should be continuation lines (if no blank space) or indented code blocks (if blank space).

    • Clarify tildes and backticks in info strings (#119). We disallow backticks in info strings after backtick fences only. Both backticks and tildes are allowed in info strings after tilde fences. Add example.

    • Indicate that info string is trimmed of all whitespace (#505, Ashe Connor). As noted in https://github.com/github/cmark/issues/60, the info string is not only trimmed of "spaces" (U+0020) but also of tabs.

    • Don't strip spaces in code span containing only spaces (#569). This allows one to include a code span with just spaces, using the most obvious syntax.

    • Add example w/ reference link w/ empty destination in <> (#172).

    • Disallow link destination beginning with < unless it is inside <..> (#538). This brings the description in line with the spec example: [foo]: (baz)

       [foo]
       .
       <p>[foo]: <bar>(baz)</p>
       <p>[foo]</p>
      
    • Allow spaces inside link destinations in pointy brackets (#503). This reverts a change in 0.24 and should make things easier for people working with image paths containing spaces.

    • Remove redundant condition. We don't need to specify that the absolute URI in an autolink doesn't contain <, since this is specified in the description of an absolute URI.

    • Add additional spec examples involving link destinations in <> (#473).

    • Add test for [test](<url\>) (#562).

    • Disallow unescaped ( in parenthesized link titles (#526).

    • Add example showing need for space before title in reference link (#469).

    • Add codepoints for punctuation characters (#564, Christoph Päper).

    • Clarify the left- and right-flanking definitions (#534, Jay Martin).

    • Match interior delimiter runs if lengths of both are multiples of 3 (#528). This gives better results on a***b***c without giving bad results on the cases that motivated the original multiple of 3 rule.

    • Add another test case for emphasis (#509, Michael Howell).

    • Code spans: don't collapse interior space (#532).

    • Simplify revisions to code span normalization rules. Remove the complex rule about ignoring newlines adjacent to spaces. Now newlines are simply converted to spaces.

    • Replace image 'url' with 'destination' (#512, Phill).

    • Add some links for occurrences of "above" (#480).

    • Various typo fixes (#514, Kenta Sato; #533, nikolas; tnaia, #556; #551, Grahame Grieve).

    • Create .gitattributes so that changelog.txt is highlighted as markdown (#499, Christoph Päper).

    • Update GitHub links (Morten Piibeleht).

    • Update references to container and leaf block headers to use the correct pluralization (#531, Elijah Hamovitz).

    • Rephrase example #111 to indicate that the rendering is not mandated (#568).

    • Improve documentation of parsing strategy (#563). Note that openers_bottom needs to be indexed to delimiter run lengths as well as types.

    • make_spec.lua: Fix migration of children nodes in create_anchors (#536, Zhiming Wang). This resulted in some bugs in the rendered spec (where words would be dropped from links).

    • Fix dingus link when double clicking Markdown code (#535, Zhiming Wang). Prior to this commit, the link opened is always /dingus/?text= (no text).

    • Add spec.json generator to Makefile (M Pacer).

    Source code(tar.gz)
    Source code(zip)
  • 0.28(Aug 2, 2017)

    • Allow unlimited balanced pairs of parentheses in link URLs (@kivikakk, jgm/cmark#166). The rationale is that there are many URLs containing unescaped nested parentheses. Note that implementations are allowed to impose limits on parentheses nesting for performance reasons, but at least three levels of nesting should be supported.

    • Change Rule 14 for Emphasis. Previously the nesting Strong (Emph (...)) was preferred over Emph (Strong (...)). This change makes Emph (Strong (...)) preferred. Note that the commonmark reference implementations were not entirely consistent about this rule, giving different results for

      ***hi***
      

      and

      ***hi****
      

      This change simplifies parsing. It goes against the majority of implementations, but only on something utterly trivial.

    • Clarify definition of delimiter runs (Aidan Woods, #485).

    • Clarify precedence of thematic breaks over list items in the list spec, not just the thematic break spec (Aidan Woods).

    • Clarify definition of link labels and normalization procedure (Matthias Geier, #479).

    • Clarify that the end of an HTML block is determined by its start, and is not changed by HTML tags encountered inside the block. Give an example of a case where a block ends before an interior element has been closed (Yuki Izumi, #459). In the future we might consider changing the spec to handle this case more intuitively; this change just documents more explicitly what the spec requires.

    • Acknowledge Aaron Swartz's role in developing Markdown.

    • Remove misleading backslash in example for disabling image markup (Matthias Geier).

    • Fix Unicode terminology (general category, not class) (Philipp Matthias Schaefer).

    • Add another illustrative case for code spans (#463).

    • Remove possibly misleading 'either's (#467).

    • Fix typo (Aidan Woods).

    • Clarify that some blocks can contain code spans (Matthias Geier).

    • Fix typo and clarified tab expansion rule (Scott Abbey).

    • Add a missing "iff" (Matthias Geier).

    • Add release checklist.

    • Added npm package for spec (Vitaly Puzrin).

    • Remove SPEC variable from Makefile.

    Source code(tar.gz)
    Source code(zip)
  • 0.26(Jul 15, 2016)

    • Empty list items can no longer interrupt a paragraph. This removes an ambiguity between setext headers and lists in cases like

      foo
      -
      

      Removed the "two blank lines breaks out of lists" rule. This is incompatible with the principle of uniformity (and indeed with the spec for list items, which requires that the meaning of a chunk of lines not change when it is put into a list item.)

    • Ordered list markers that interrupt a paragraph must start with 1.

    • Improved the section on tabs. Added some test cases for ATX headers and thematic breaks. Clarified that it's not just cases that affect indentation that matter, but all cases where whitespace matters for block structure.

    • Removed example of ATX header with tab after #.

    • Allow HTML blocks to end on the last line of their container (Colin O'Dell, #103).

    • Spec changes in strong/emph parsing. See https://talk.commonmark.org/t/emphasis-strong-emphasis-corner-cases/2123 for motivation. This restores intuitive parsings for a number of cases. The main change is to disallow strong or emph when one of the delimiters is "internal" and the sum of the lengths of the enclosing delimiter runs is a multiple of 3. Thus, **foo*bar*** gets parsed <strong>foo*bar</strong> rather than <em><em>foo</em>bar</em>** as before. Thanks to Fletcher Penney for discussion.

    • Add tests to check that markdown parsing is working fine after an HTML block end tag (Alexandre Mutel).

    • Add test case for nested lists with an indent > 4 (Alexandre Mutel).

    • Cleaned up terminology around lazy continuation lines. Added some links.

    • Fixed broken links and typos (Artyom, Matthias Geier, Sam Estep).

    • Use instead of < in list item spec for clarity.

    • Add point about readibility to "What is Markdown" section.

    • Add example for list item starting with a blank line with spaces (Robin Stocker).

    • Make interact more button-like and clearer (Jeff Atwood).

    • spec_tests.py: exit code is now sum of failures and errors.

    • spec_tests.py: specify newline when opening file.

    Source code(tar.gz)
    Source code(zip)
  • 0.25(Jul 15, 2016)

    • Added several more tab-handling cases (see jgm/cmark#101).
    • Fixed spec test for tabs. In the blockquote with a tab following the >, only one space should be consumed, yielding two spaces at the beginning of the content.
    • Update license year range to 2016 (Prayag Verma).
    • Fixed typo: setext heading line -> setext heading underline (#389).
    • Fixed date 2015->2016 (#388)
    Source code(tar.gz)
    Source code(zip)
  • 0.24(Jan 13, 2016)

    [0.24]

    • New format for spec tests, new lua formatter for specs. The format for the spec examples has changed from

      .
      markdown
      .
      html
      .
      

      to

      ```````````````````````````````` example
      markdown
      .
      html
      ````````````````````````````````
      

      One advantage of this is that spec.txt becomes a valid CommonMark file.

    • Change tests/spec_test.py to use the new format.

    • Replace tools/makespec.py with a lua script, tools/make_spec.lua, which uses the lcmark rock (and indirectly libcmark). It can generate HTML, LaTeX, and CommonMark versions of the spec. Pandoc is no longer needed for the latex/PDF version. And, since the new program uses the cmark API and operates directly on the parse tree, we get much more reliable translations than we got with the old Python script (#387).

    • Remove whitelist of valid schemes. Now a scheme is any sequence of 2-32 characters, beginning with an ASCII letter, and containing only ASCII letters, digits, and the symbols -, +, .. Discussion at http://talk.commonmark.org/t/555.

    • Added an example: URI schemes must be more than one character.

    • Disallow spaces in link destinations, even inside pointy braces. Discussion at http://talk.commonmark.org/t/779 and http://talk.commonmark.org/t/1287/12.

    • Modify setext heading spec to allow multiline headings. Text like

      Foo
      bar
      ---
      baz
      

      is now interpreted as heading + paragraph, rather than paragraph + thematic break + paragraph.

    • Call U+FFFD the REPLACEMENT CHARACTER, not the "unknown code point character."

    • Change misleading undefined entity name example.

    • Remove misleading claim about entity references in raw HTML (a regression in 0.23). Entity references are not treated as literal text in raw HTML; they are just passed through.

    • CommonMark.dtd: allow item in custom_block.

    Source code(tar.gz)
    Source code(zip)
  • 0.23(Dec 29, 2015)

    [0.23]

    • Don't allow space between link text and link label in a reference link. This fixes the problem of inadvertent capture:

      [foo] [bar]
      
      [foo]: /u1
      [bar]: /u2
      
    • Rename "horizontal rule" -> "thematic break". This matches the HTML5 meaning for the hr element, and recognizes that the element may be rendered in various ways (not always as a horizontal rule). See http://talk.commonmark.org/t/horizontal-rule-or-thematic-break/912/3

    • Rename "header" -> "heading". This avoids a confusion that might arise now that HTML5 has a "header" element, distinct from the "headings" h1, h2, ... Our headings correspond to HTML5 headings, not HTML5 headers. The terminology of 'headings' is more natural, too.

    • ATX headers: clarify that a space (or EOL) is needed; other whitespace won't do (#373). Added a test case.

    • Rewrote "Entities" section with more correct terminology (#375). Entity references and numeric character references.

    • Clarified that spec does not dictate URL encoding/normalization policy.

    • New test case: list item code block with empty line (Craig M. Brandenburg).

    • Added example with escaped backslash at end of link label (#325).

    • Shortened an example so it doesn't wrap (#371).

    • Fixed duplicate id "attribute".

    • Fix four link targets (Lucas Werkmeister).

    • Fix typo for link to "attributes" (Robin Stocker).

    • Fix "delimiter" spellings and links (Sam Rawlins).

    • Consistent usage of "we" instead of "I" (renzo).

    • CommonMark.dtd - Rename html -> html_block, inline_html -> html_inline for consistency. (Otherwise it is too hard to remember whether html is block or inline, a source of some bugs.)

    • CommonMark.dtd - added xmlns attribute to document.

    • CommonMark.dtd - added custom_block, custom_inline.

    • CommonMark.dtd - renamed hrule to thematic_break.

    • Fixed some HTML inline tests, which were actually HTML blocks, given the changes to block parsing rules since these examples were written (#382).

    • Normalize URLs when comparing test output. This way we don't fail tests for legitimate variations in URL escaping/normalization policies (#334).

    • normalize.py: don't use HTMLParseError, which has been removed as of python 3.5 (#380).

    • Minor spacing adjustments in test output, to match cmark's output, since we test cmark without normalization.

    • makespec.py: remove need for link anchors to be on one line.

    • makespec.py: Only do two levels in the TOC.

    • Use display:inline-block rather than floats for side-by-side. This works when printed too.

    • Added better print CSS.

    Source code(tar.gz)
    Source code(zip)
  • 0.21(Jul 15, 2015)

    • Changed handling of tabs. Instead of having a preprocessing step where tabs are converted to spaces, we now handle tabs directly in the parser. This allows tabs to be retained in code blocks and code spans. This change adds some general language to the effect that, for purposes of determining block structure, tabs are to be treated just like equivalent spaces.
    • Completely rewrote spec for HTML blocks. The new spec provides better handling of tags like <del>, which can be either block or inline level content, better handling of custom tags, and better handling of verbatim contexts like <pre>, comments, and <script>.
    • Added 9-digit limit on ordered list start number. Some browsers use signed 32-bit integers for indexing the items of an ordered list, and this can lead to odd or undefined behavior if 10-digit start numbers are allowed.
    • Allow (non-initial) hyphens in tag names (#239). Custom tags in HTML5 must contain hyphens.
    • Clarified that HTML block is closed at end of containing block, not just end of the document (as with fenced code blocks.)
    • Specify nested link definition behavior in prose (Benjamin Dumke-von der Ehe).
    • Added test for edge case in link reference parsing (Benjamin Dumke-von der Ehe, see jgm/commonmark.js#49).
    • Added link tests with fragment identifiers and queries (David Green, #342).
    • Added test cases with a literal backslash in a link destination (see jgm/commonmark.js#45).
    • Added test for entity &ngE; which resolves to two code points. Put entity tests on several lines for readability (see jgm/commonmark.js#47).
    • Fixed broken "pre" literal HTML example. Contents weren't escaped properly.
    • Simplified defn of "unicode whitespace character," rectifying omission of line tabulation, U+000B (#343).
    • Removed ambiguity in definition of "line" (#346).
    • Rewrapped two prose lines so + does not begin a line (#347).
    • Added another test with overlapping emphasis markers.
    • Fixed link to 'attributes'.
    • Revised appendix, "A parsing strategy," and added a description of emphasis/link parsing algorithm.
    • spec_tests.py - set options for conversions, set library paths in a more cross-platform way.
    • spec_tests.py: force utf-8 on test failure output and --dump-tests (#344, #345).
    • spec_tests.py: Properly handle visible tab in expected output.
    • normalize.py: Don't collapse whitespace inside pre tag.
    • Added spec.html to .gitignore (#339).
    • Add -dev suffix to spec version after release (eksperimental).
    • Rename "non-space" to "non-whitespace" (Konstantin Zudov, #337).
    Source code(tar.gz)
    Source code(zip)
  • 0.20(Jun 8, 2015)

    • Require at least one nonspace character in a link label (#322).
    • Require replacement (rather than omission) of U+0000 (#327).
    • Clarified that entities resolving to U+0000 are to be replaced by U+FFFD (#323).
    • Removed statement that what counts as a line ending is platform-dependent (#326). We now count \r, \n, or \r\n as a line ending regardless of the platform. (The line ending styles can even be mixed in a single document.)
    • Defined "space."
    • Revised "non-space character". Previously a non-space character was defined as anything but a space (U+0020). Now it is anything that is not a whitespace character (as defined in the spec).
    • Clarified that tab expansion is a preprocessing step (#330).
    • Clarified lazy block quote examples (#328).
    • Clarified precedence of indentation that meets conditions for both list item continuation blocks and indented code.
    • Added a test case with # directly followed by a letter (not an ATX header).
    • Added two test cases illustrating that a list at the outer level can have items that are indented by more than four spaces (see commonmark.js#42 and http://talk.commonmark.org/t/odd-list-behaviour/1189).
    • Fixed typo in emphasis examples.
    Source code(tar.gz)
    Source code(zip)
  • 0.19(Apr 29, 2015)

    • Fixed rules for _-based emphasis and strong emphasis (#317). Previously _(bar)_. was not parsed as containing emphasis because the closing delimiter is both left- and right- flanking. This fix allows such delimiters, provided they're followed by punctuation (i.e., they have punctuation on both sides). Similarly, mutatis mutandis, for opening delimiters and for __.
    • Clarified definitions of left-flanking and right-flanking (#310). The spec now says explicitly that the beginning and end of line count as whitespace for purposes of this definition.
    • Clarified that a code fence followed by header line isn't a header (#306).
    • Fixed alignment in flankingness examples (cosmetic).
    • Fixed last "right flanking but not left flanking" example (#316).
    • Fixed a broken link (Konstantin Zudov).
    • Added link to list of implementations on wiki.
    • Fixed mistake in examples of left/right flanking delimiters (Konstantin Zudov).
    • Spell out iff (if and only if) the first time it is used (#309).
    • Fixed typos (isoroku, #309).
    • Clarified wording for soft line break: newline can't be preceded by two spaces or a backslash.
    • Replaced some references to UTF-8 that should be to unicode.
    • Fixed dingus link in tools/template.html.
    • Replaced obsolete reference to spec2md.pl in spec (#304).
    Source code(tar.gz)
    Source code(zip)
  • 0.18(Mar 4, 2015)

    • Added a shortcut link test with mismatched brackets (#282).

    • Added cases with newline whitespace around emphasis open delimiter (#282).

    • Added list item examples with no space after marker (#282).

    • Added additional test showing backslash escapes don't work in autolinks (#282).

    • Added test for multiline title in reference definition (#282).

    • Added a reference link definition test case (#282).

    • Clarified that link titles can't contain blank lines (#271).

    • Revised Rule 3 for list items (#275). Previously this just applied to empty list items. It has been rewritten to apply to any list item starting with a blank line, including items like:

      -
        ```
        code
        ```
      
    • Added U+000B and U+000C as whitespace characters (#300).

    • Added comment on sourcepos attribute format in DTD (#298).

    • Use --smart option in producing HTML version of spec.

    • Clarified that delimiter runs at beginning/end of line behave as if preceded/followed by whitespace (#302).

    • Ensure that URLs in examples have slash after domain. This helps with #9, making these tests less sensitive to the normalizer used.

    • Fixed typo (Robin Stocker).

    Source code(tar.gz)
    Source code(zip)
  • 0.17(Jan 25, 2015)

    Note: with this release, we have split off the reference implementations into separate repositories. The JavaScript implementation is in https://github.com/jgm/commonmark.js, and the C implementation is in https://github.com/jgm/cmark. This repository contains the spec and tools for formatting the spec and running tests against it.

    Spec changes:

    • Improved rule limiting intraword _ for emphasis and strong emphasis. To prevent intra-word emphasis, we used to check to see if the delimiter was followed/preceded by an ASCII alphanumeric. We now do something more elegant: whereas an opening * must be left-flanking, an opening _ must be left-flanking and not right-flanking. And so on for the other cases. All the original tests passed except some tests with Russian text with internal _, which formerly created emphasis but no longer do with the new rule. These tests have been adjusted. A few new test cases have been added to illustrate the rule.
    • Added example with link break inside pointy braces (no link) (#295).
    • Added spec example: loose list with blank line after fenced code (#285).
    Source code(tar.gz)
    Source code(zip)
  • 0.16(Jan 15, 2015)

    Spec changes

    • Rewrote beginning of Entities section, clarifying that only entities not in code blocks or spans are decoded.
    • Removed defective Example 449 (#284).
    • Fixed typo (#283).
    • Added intended two-space hard-breaks in Examples 521, 523.
    • Clarified that brackets in general don't take precedence over emph (#258).
    • Clarified that final newline is removed from paragraph content (#176).
    • Talk of "info string" rather than "attributes" for code blocks (#262).
    • Clarified precedence of code spans, HTML tags, autolinks (#259).
    • Fixed a number of internal links and duplicate references in the spec.
    • Linkify "info string" in spec.
    • Use shortcut reference links when possible in spec.txt.
    • cmark itself is now used to build spec.html, rather than pandoc.
    • Use shortcut reference links when possible in spec.txt. This relies on the new spec2md.py behavior of creating references for all internal anchors.
    • Moved some examples from block to inline HTML section.
    • Added examples of non-comments (#264).
    • Changed rule for comments to conform to HTML5 spec.
    • Made clear that any sequence of characters is a valid document (#266).
    • Changed wording: "is preferred" -> "takes precedence."
    • Regularized spelling of "non-space character" and added links (#260).
    • Use four spaces rather than five to show "four spaces is too much" (#261).

    cmark/libcmark

    • Added xml renderer (XML representation of the CommonMark AST, which is described in CommonMark.dtd).
    • Reduced size of gperf entity table (Nick Wellnhofer).
    • Reworked iterators to allow deletion of nodes during iteration (Nick Wellnhofer).
    • Optimized S_is_leaf.
    • Added cmark_iter_reset to iterator API.
    • Added cmark_consolidate_text_nodes to API to combine adjacent text nodes.
    • Added CMARK_OPT_NORMALIZE to options (this combines adjacent text nodes).
    • Added --normalize option to command-line program.
    • Improved regex for HTML comments in inline parsing.
    • Python is no longer required for a basic build from the repository.

    commonmark.js

    • Improved regex for HTML comments (#263).
    • Fixed CDATA regex (#267).
    • Use linked list instead of arrays in AST: the same doubly linked node structure as cmark uses. This simplifies some code and eliminates the need for recursive algorithms, so we can render deeply-nested structures without stack overflows.
    • Use children instead of label (in Image and Link), inline_content (in Paragraph), and c (in Emph and Strong).
    • Renamed the c property to literal to match libcmark.
    • Use literal rather than string_content property for code blocks, HTML. string_content is reserved for raw string content that has yet to be parsed as inlines.
    • Improved end lines (#276).
    • Added a node walker, for easy AST traversal (see node.js).
    • Regularized position information into a sourcepos property. Added end column information.
    • Renamed html-renderer.js to html.js.
    • Replace NUL characters with U+FFFD, as per spec.
    • Optimized code, resulting in significant performance gains. (We've gone from being twice as fast as showdown.js to being three times as fast, on par with marked.)
    • Made tight a property of list_data rather than Node.
    • Added options to renderer, parser objections.
    • Added a --sourcepos command line option to js/bin/commonmark.
    • HTML renderer now throws an error on unknown tag type (which indicates a programming error).
    • Removed ansi.js code from the source tree. The test suite now uses its own mini ansi colors implementation.
    • Added --time option to js/bin/commonmark.
    • Added an XML renderer (XML representation of the AST, matching Commonmark.dtd).
    • Changed url property to destination to match cmark and spec.
    • Added js/common.js to hold some common code, like string unescaping and URI normalization.
    • Use decodeURI instead of unescape.
    • Added some "pathological" test cases to test suite.
    Source code(tar.gz)
    Source code(zip)
Owner
CommonMark
A strongly specified, highly compatible implementation of Markdown
CommonMark
Sorting routine implementations in "template" C

sort.h Overview sort.h is an implementation of a ton of sorting algorithms in C with a user-defined type that is provided at include time. This means

Christopher Swenson 391 Jun 21, 2022
Crown (formerly Crowncoin) reference implementation

Crown Core integration/staging tree https://crownplatform.com What is Crown? Crown is an experimental digital currency that enables instant payments t

Crown Platform 4 May 31, 2022
fast javascript bundler :package:

Fast JavaScript Bundler https://fjbundler.com What? It is what it says it is. However, this bundler aims to be a monolithic does-it-all type of bundle

Sebastian Karlsson 101 Apr 17, 2022
libcurses and dependencies taken from netbsd and brought into a portable shape (at least to musl or glibc)

netbsd-libcurses portable edition this is a port of netbsd's curses library for usage on Linux systems (tested and developed on sabotage linux, based

null 119 Jun 19, 2022
Sqrt OS is a simulation of an OS scheduler and memory manager using different scheduling algorithms including Highest Priority First (non-preemptive), Shortest Remaining Time Next, and Round Robin.

A CPU scheduler determines an order for the execution of its scheduled processes; it decides which process will run according to a certain data structure that keeps track of the processes in the system and their status. A process, upon creation, has one of the three states: Running, Ready, Blocked (doing I/O, using other resources than CPU or waiting on unavailable resource).

Abdallah Hemdan 18 Apr 15, 2022
The lightweight and modern Map SDK for Android and iOS

Open Mobile Maps The lightweight and modern Map SDK for Android (6.0+) and iOS (10+) openmobilemaps.io Getting started Readme Android Readme iOS Featu

Open Mobile Maps 90 Jun 13, 2022
Indexes points and lines and generates map tiles to display them

Datamaps This is a tool for indexing large lists of geographic points or lines and dynamically generating map tiles from the index for display. Depend

Eric Fischer 328 Jun 16, 2022
A LKM rootkit targeting 4.x and 5.x kernel versions which opens a backdoor that can be used to spawn a reverse shell to a remote host and more.

Umbra Umbra (/ˈʌmbrə/) is an experimental LKM rootkit for kernels 4.x and 5.x (up to 5.7) which opens a network backdoor that spawns reverse shells to

Marcos S. Bajo 76 Jun 18, 2022
A cross-platform OpenXR capabilities explorer and runtime switcher with a CLI and GUI.

OpenXR Explorer OpenXR Explorer is a handy debug tool for OpenXR developers. It allows for easy switching between OpenXR runtimes, shows lists of the

Nick Klingensmith 116 Jun 26, 2022
Simple and lightweight pathname parser for C. This module helps to parse dirname, basename, filename and file extension .

Path Module For C File name and extension parsing functionality are removed because it's difficult to distinguish between a hidden dir (ex: .git) and

Prajwal Chapagain 3 Feb 25, 2022
Compile and execute C "scripts" in one go!

c "There isn't much that's special about C. That's one of the reasons why it's fast." I love C for its raw speed (although it does have its drawbacks)

Ryan Jacobs 1.9k Jun 17, 2022
A shebang-friendly script for "interpreting" single C99, C11, and C++ files, including rcfile support.

c99sh Basic Idea Control Files Shebang Tricks C++ C11 Credits Basic Idea A shebang-friendly script for "interpreting" single C99, C11, and C++ files,

Rhys Ulerich 100 Jun 9, 2022
A tool for use with clang to analyze #includes in C and C++ source files

Include What You Use For more in-depth documentation, see docs. Instructions for Users "Include what you use" means this: for every symbol (type, func

null 2.9k Jul 2, 2022
SMACK Software Verifier and Verification Toolchain

SMACK is both a modular software verification toolchain and a self-contained software verifier. It can be used to verify the assertions in its input p

null 375 Jun 19, 2022
A C library for parsing/normalizing street addresses around the world. Powered by statistical NLP and open geo data.

libpostal: international street address NLP libpostal is a C library for parsing/normalizing street addresses around the world using statistical NLP a

openvenues 3.5k Jun 29, 2022
A small self-contained alternative to readline and libedit

Linenoise A minimal, zero-config, BSD licensed, readline replacement used in Redis, MongoDB, and Android. Single and multi line editing mode with the

Salvatore Sanfilippo 3k Jun 25, 2022
WAFer is a C language-based software platform for scalable server-side and networking applications. Think node.js for C programmers.

WAFer WAFer is a C language-based ultra-light scalable server-side web applications framework. Think node.js for C programmers. Because it's written i

Riolet Corporation 692 Jun 3, 2022
tiny recursive descent expression parser, compiler, and evaluation engine for math expressions

TinyExpr TinyExpr is a very small recursive descent parser and evaluation engine for math expressions. It's handy when you want to add the ability to

Lewis Van Winkle 1.1k Jun 24, 2022
timers and timeline

⏱ Timer and Timeline Utils for C This library provides an easy way to set timers and timeouts. As initial version all timers run in single runloop at

Recep Aslantas 32 Jun 7, 2022