md_is_code_span(), called from md_collect_marks().
We have to do this at the same time as detecting raw inline HTML to
follow CommonMark priority requirements.
Also it is done very differently now:
When scanning for the closer mark, we remember (the latest) position of
potential closers for all other lengths as well.
This means that:
(1) If we find it, we reduced the task because all subsequent scan shall
begin after the closer.
(2) If we do not find it, then we have to reach the end of the block and
hence we then know (for every allowed marker length) the position of last
such backtick sequence.
(3) That makes the guaranty that any subsequent call with either succeed
in its scan (and reduce the task even further); or that we shall be able
to detect instantly there is no suitable closer.
I.e. every call either reduces the task by O(n) scan (1); or collects
all the data in O(n) because (2) happens at most once; or fails in O(1)
(3).
This makes O(n) guaranty of the function complexity.
Fixes#59.
Fixes#58:
For resolving raw inline HTML the function tried closer with all
potential openers, because raw HTML can have '<' inside of an attribute.
However this caused O(n^2) for input like "<><><><><><><>...".
We solved by handling raw HTML in earlier stage, directly in
md_collect_marks(), where we can scan linerary forward.
Fixes#61:
As a side effect, this also fixes the issue that MD_FLAG_NOHTMLSPANS
disabled also recognition of CommonMark autolinks.
The issues is caused by the fact that we do not know exact position
of permissive auto-link in time of md_collect_marks() because there
is no syntax to mark its end on the 1st place.
This causes that eventually, the closer mark in ctx->marks[] can be
out-of-order somewhat.
As a consequence, if some other mark range (e.g. ordinary link)
shadows the auto-link, the closer mark may be left outside the shadowed
range and survive till the phase when we generate the output.
We fix by using an extra mark flag to remember we did really output
the opener mark, and output the closer only in such case.
Fixes#53.
If table header underline is not nested the same way as the preceding
line (i.e. the wannabe table header line), then it cannot form a table.
Fixes#41.
This changes causes that when recursing to analysis of link contents,
only the marks between the link opener and closer are iterated in
md_analyze_marks().
Fixes#22
If the first emphasis opener is refused due the rule of three, a previous
opener is examined. However the variable opener_orig_size_module3 was not
(re)set accordingly.
Fixes#21.
It now uses FNV1a and we now sort/bsearch only contents of single bucket.
Additionally we fix#20 by disabling the invalid ref. definitions during
hashtable build.
It is now much more compatible to Cmark-gfm.
With the flag MD_FLAG_PERMISSIVEWWWAUTOLINKS, we now also support the
WWW autolinks (when the http: scheme is omitted).
Calling md_push_container_bytes() may result in ending a current block
which may result in removing some contents from ctx->block_bytes when
removing some lines with link reference definitions.
This in effect means we have to end the block explicitly before storing
the offset into the ctx->block_bytes.
Remove MD_SPAN_IMG_DETAIL::alt. Instead, the contents of the image is
propagated to the renderer via MD_RENDERER::text() callback.
* This fixes handling of entities inside the image text (issue #4).
* It simplifies parsing and, more importantly, it better distingusshes
what is responsibility of parser or renderer respectively.
* This allows more flexibility on renderers side. Renderer who do not
* really support images can just output the image content as any
other text.
The cost is a renderer into HTML (if it wants to render image contents
into the attribute ALT of the IMG tag), has to handle images with more
care. Typically such renderer has to track whether it is inside an image,
and if so, then render span enter/leave as an empty string.
With MD_FLAG_PERMISSIVEURLAUTOLINKS, we treat not overly complicated URLs
as autolinks even without '<' and '>'.
With MD_FLAG_PERMISSIVEEMAILAUTOLINKS, we treat not overly complicated
e-mail addresses as autolinks even without '<', '>' and without the
'mailto:' scheme.
Also expanded md2html utility and tests to cover these.
