| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Preserving general pre-existing title output, ensure that image URL can have spaces (ref #590).
|
| |
|
| |
|
|
|
|
|
| |
This aims to escape code in a more expected fashion. This handles
when backticks are escaped and when the escapes before backticks are
escaped.
|
|
|
|
| |
This fixes warnings with pycodestyle ≥ 2.1, see PyCQA/pycodestyle#400.
|
|
|
|
|
| |
Don’t allow spaces in image links. This was also causing an issue
where any text following a space was treated as a title. Ref #484.
|
|
|
|
|
|
| |
Drppoed the non-greedy quantifier from the end of the inlinePatterns as it
served no useful purpose and was actually (in very rare edge cases) causing
newlines to be dropped. FIxes #439. Thanks to @munificent for the report.
|
|
|
|
|
|
|
| |
Apparently this is a new requirement of flake8. That's the thing about using
tox. Every test run reinstalls all dependencies so an updated dependency might
instroduce new errors. I could specify a specific version, but I like staying
current.
|
|
|
|
|
|
| |
Got all but a couple files in the tests (ran out of time today).
Apparently I have been using some bad form for years (although a few
things seemed to look better before the update). Anyway, conformant now.
|
|
|
|
|
|
|
|
|
|
|
| |
The logic for the current regex for strong/em and em/strong was sound,
but the way it was implemented caused some unintended side effects.
Whether it is a quirk with regex in general or just with Python’s re
engine, I am not sure. Put basically `(\*|_){3}` causes issues with
nested bold/italic. So, allowing the group to be defined, and then
using the group number to specify the remaining sequential chars is a
better way that works more reliably `(\*|_)\2{2}. Test from issue #365
was also added to check for this case in the future.
|
|
|
|
|
|
|
|
|
| |
Fixes #253. Thanks to @facelessuser for the tests. Although I removed
a bunch of weird ones (even some that passed) from his PR (#342). For
the most part, there is no definitive way for those to be parsed. So
there is no point of testing for them. In most of those situations,
authors should be mixing underscores and astericks so it is clear
what is intended.
|
|
|
|
|
|
| |
See #253. Prior to this patch, if any inline processors returned an element
with a tail, the tail would end up empty. This resolves that issue and will
allow for #253 to be fixed. Thanks to @facelessuser for the work on this.
|
|
|
|
|
|
| |
These couple lines were from an old - no longer used - method of
stashing inlines. There is no need for it today. The if statement would
never evaluate True.
|
|
|
|
| |
The rest should have test cases added.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation was wrong as it also percent encoded query strings
(which should be plus encoded) and calling urllib.quote on the path (and
urllib.quote_plus on the query string) assumes the url is not already encoded.
What if the document author pasted a url that was already encoded? She probably
did not intend for `%20` to become `%2520`. Or did she? It is now clear to me
why many implementation do nothing to urls. Just pass them though as-is. To bad
if they are not valid HTML. HTML authors have to encodee their own urls, so I
guess markdown authors have to as well.
|
|
|
|
|
|
| |
Leave all other chars prefaced by a backslash alone. Fixes #242.
Not sure why I thought that I needed to add another backslash.
Thanks for the report and the test case @mhubig.
|
| |
|
|
|
|
|
|
|
|
|
| |
A `from __future__ import ...` statement must go after any docstrings;
since putting them before the docstring means the docstring loses its
magic and just becomes a string literal. That then causes a syntax
error if there are further future statements after the false docstring.
This fixes issue #203, using the patch provided by @Arfrever.
|
|
|
|
|
|
|
|
|
|
| |
The most notable changes are the use of unicode_literals
and absolute_imports. Actually, absolute_imports was the
biggest deal as it gives us relative imports. For the first
time extensions import markdown relative to themselves.
This allows other packages to embed the markdown lib in a
subdir of their project and still be able to use our
extensions.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
only of an Element - rather than the html which just gets html escaped in the output anyway.
|
| |
|
|
|
|
| |
placeholder is an Elementtree Element.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Not only does this ensure that all output matches the output_format,
but it is nessecary to run in Python 3.
|
|
|
|
|
|
|
|
| |
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!
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
|
|
|
| |
brackets in reference links. Now we do as well.
|
| |
|
|
|
|
| |
they are removed before escaping takes place. Related to issue #14.
|
|
|
|
| |
uppears that we are loosing escaped backslashes (both in the href and in the link label in the example given in issue 14.
|
|
|
|
| |
from tests/pl/Tests_2007/. Namely, improved simple reference links and fixed a small issue with titles in links.
|
|
|
|
| |
links; i.e., [this works]. Associated with and noted as missing when debuging Ticket 79.
|
|
|
|
| |
This matches the most recent version of markdown.pl among other implementations and allows links to work after editors do autolinebreak stuff to text.
|
|
|
|
| |
will match unicode characters when \w, \b, or \s is used. Also updated docs to reflect change.
|
|
|
|
| |
only officially support Python 3.1+ in the Python 3 series (we still support 2.4, 2.5 & 2.6 in the Python 2 series). If you really must use Python 3.0, we suggest using Python 3.1's 2to3 tool. See comment in source and Ticket 66 for more.
|
|
|
|
| |
should be more future proof.
|
|
|
|
| |
utility functions called by a build_parser method on the Markdown class. Editing of the processors and patterns now all happen in one file for each type. Additionaly, a subclass of Markdown could potentially override the build_parser method and build a parser for a completely differant markup language without first building the default and then overriding it.
|