| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Final fix to issue introduced in fix for #59. Weird stuff inside
angle brackets now also work in safe_mode='escape'. We just did the
same thing as with block html, let the (x)html searializer do the
escaping. Tests updated including the standalone test moved to match
the non-escape cases.
|
|
|
|
|
| |
Markdown markup inside angle bracktes now gets rendered properly
in all cases except when safe_mode='escape'. Also added tests.
|
|
|
|
|
|
| |
Replaced the unescape method I carlessly threw in the RawHtmlProcessor.
Unfortunetly, this reintroduces the bug just fixed in commit
425fde141f17973aea0a3a85e44632fe18737996 Sigh!
|
|\
| |
| |
| |
| | |
Conflicts:
markdown/inlinepatterns.py
|
| |
| |
| |
| | |
type.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
See tests/html4_safe/html_then_blockquote.(txt|html).
It looks like having unclosed block-level html elements was causing
further processing not to happen, even in the case where we're
escaping HTML. Since we're escaping HTML, it seems like it shouldn't
affect processing at all. This changes output results in a couple
of other tests, but the new output seems reasonable to me.
|
| | |
|
| |
| |
| |
| |
| | |
Interestingly, the change to the misc/mismatched-tags test is inline with
PHP Markdown Extra's behavior but not markdown.pl, which produces invalid html.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Apparently, in Python3 stdin and stdout take str (unicode) not bytes.
This provides a solution that will work in both python 2 & 3.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also optimized the code to bypass parsing when not in safe_mode and return
immediately upon failure rather than continue parsing when in safe_mode.
Note that in Python2.7+ more urls may fail than in older versions because
IPv6 support was added to urlparse and it apparently mistakenly identifies some
urls as IPv6 when they are not. Seeing this only applies to safe_mode now,
I don't really care.
|
| |
| |
| |
| | |
work with it.
|
| |
| |
| |
| | |
capitalized. Thanks for the report.
|
| |
| |
| |
| |
| | |
I accidentally changed the wrong line (L294 instead of L293) to
"self.footnotes.getConfig("BACKLINK_TEXT")" before. This fixes that.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
BACKLINK_TEXT specifies the text that's used in the link at the end of
the footnote to link back up to the reader's place. It still defaults to
"↩".
Okay, so at first I had an uncessarily complicated commit for this and
submitted a pull request. Waylan showed me a better way to do it, here:
https://github.com/startling/Python-Markdown/commit/ee7d1a26c76f970c12226ca48ba52dc1d32f2488#markdown/extensions/footnotes.py-P19
So I made another commit and added it to the pull request. But then I
accidentally added yet another commit to the pull request, accidentally.
Since then, I've realized it would be best to start with a new branch
and closed that first pull request.
Hopefully this will be the last try.
|
| |
| |
| |
| | |
mode on.
|
| | |
|
| |
| |
| |
| |
| | |
Interestingly, the change to the misc/mismatched-tags test is inline with
PHP Markdown Extra's behavior but not markdown.pl, which produces invalid html.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Apparently, in Python3 stdin and stdout take str (unicode) not bytes.
This provides a solution that will work in both python 2 & 3.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also optimized the code to bypass parsing when not in safe_mode and return
immediately upon failure rather than continue parsing when in safe_mode.
Note that in Python2.7+ more urls may fail than in older versions because
IPv6 support was added to urlparse and it apparently mistakenly identifies some
urls as IPv6 when they are not. Seeing this only applies to safe_mode now,
I don't really care.
|
| |
| |
| |
| | |
work with it.
|
| |
| |
| |
| | |
capitalized. Thanks for the report.
|
|\|
| |
| | |
Allow backticks in addition to tildes for code blocks in the fenced_code extension
|
| |
| |
| |
| | |
extension source
|
| |
| |
| |
| | |
used by github
|
| |
| |
| |
| |
| | |
I accidentally changed the wrong line (L294 instead of L293) to
"self.footnotes.getConfig("BACKLINK_TEXT")" before. This fixes that.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BACKLINK_TEXT specifies the text that's used in the link at the end of
the footnote to link back up to the reader's place. It still defaults to
"↩".
Okay, so at first I had an uncessarily complicated commit for this and
submitted a pull request. Waylan showed me a better way to do it, here:
https://github.com/startling/Python-Markdown/commit/ee7d1a26c76f970c12226ca48ba52dc1d32f2488#markdown/extensions/footnotes.py-P19
So I made another commit and added it to the pull request. But then I
accidentally added yet another commit to the pull request, accidentally.
Since then, I've realized it would be best to start with a new branch
and closed that first pull request.
Hopefully this will be the last try.
|
| |
|
|
|
|
| |
code to provide a few other minor improvements s that output more closely matches php's output. Thus the changes in the tests.
|
|
|
|
| |
atomic grouping, which was slowing the HR regex down if a long HR ended with a non HR char (casing the regex to backtrack). Therefore, we have to simulate atomic grouping. Fortunately, we only need to match end-of-line or end-of-string after the atomic group here, so it was an easy case to simulate. Just remove the '$' from the end of the regex and manualy check using m.end(). The run method was refactored while I was at it, saving us from running the regex twice for each HR.
|
|
|
|
| |
someday we will better support any input (patches welcome), but we should never crash on poorly formatted input text. With this fix, we catch the exception and skip over it. The TOC up to the point (and perhaps after) still gets rendered. The incomplete TOC should be the clue to the document author that s/he has a formatting error in the document.
|
| |
|
| |
|
|
|
|
| |
from the command line style syntax for passing in bool type extension configs. In order words, we now except strings in addition to booleans and integers.
|
|
|
|
| |
it even though it is not documented.
|
|
|
|
| |
chars (the set defined by JG in the syntax rules). All other backslashes are passed through unaltered by the parser. If extensions want to add to the escapable chars, they can append to the list at markdown.ESCAPED_CHARS.
|
|
|
|
| |
if a marker was not found in the document.
|
| |
|
|
|
|
| |
[options] [args]'. I suspect will drop the command line script (markdown_py) when we drop support for Python 2.4 as this is easier to support.
|
| |
|
|
|
|
| |
only the commandline script did.
|
|
|
|
| |
of python. Note: one test (meta) is still failing on Python 3 due to unicode strings.
|
|
|
|
| |
function. The url is being encoded (with errors ignored) as an easy means of removing non-ascii chars, but we have to re-encode it *before* running the regex on it, not after.
|
|
|
|
| |
positional arguments back then.
|
|
|
|
| |
handler. Also added a note to the docs. Anyone doing their own encoding of output should be as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Those extra steps always bothered me as being unnecessary. Additionally, this
should make conversion to Python 3 easier. The 2to3 tool wasn't converting
the searializers properly and we were getting byte strings in the output.
Previously, this wasn't a major problem because the default searializer was
the xml searializer provided in the ElementTree standard lib. However, now
that we are using our own xhtml searializer, it must work smoothly in all
supported versions.
As a side note, I believe the thought was that we needed to do the encoding to
take advantage of the "xmlcharrefreplace" error handling. However, using the
example in the python [docs](http://docs.python.org/howto/unicode.html#the-unicode-type):
>>> u = unichr(40960) + u'abcd' + unichr(1972)
>>> u.encode('utf-8', 'xmlcharrefreplace').decode('utf-8') == u
True
There's no point of using the "xmlcharrefreplace" error handling if we just
convert back to the original Unicode anyway. Interestingly, the Python 3
standard lib is doing essentially what we are doing here, so I'm convinced this
is the right way to go.
|