| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Originally there was an infinite loop issue that was patched in issue
#308. Unfortunately, it was fixed all the way. This fix patches the
infinite loop fix to only add an offset to the `right_listindex` when
it is in a infinite loop scenario.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #257 and slightly alters comment parsing behavior.
Unlike self-closing tags, a comment can contain angle brackets between the
opening and closing tags. The greaterthan angle bracket at the end of the
first block should not be mistaken for closing the comment. Need to actually
check for a comment closing tag (`-->`). If one if not found, then the comment
keeps going (to the end of the document if nessecary) just like in HTML.
That last bit is a slight change from previous behavior, but should be
unsurprising as that's how broswers parse html comments. And as far as
I can tell, more implementations follow this behavior than any other. The
ones that don't seem to be all over the place.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #183. Finally got this working properly. The key was
using a regex substitution with non-overlapping matches that
removed all whitespace from the begining of *all* blank lines
when normalizing whitespace.
Once I got that, I could simplfy the EmptyBlockProcessor
and easily output one or two blank lines appropriately.
A blank block gets two new lines (`'\n\n'`), while a
block which starts with a newline gets one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #150 - at least as much as I'm willing to. This allows whitespace
normalization to be overridable by the extension API. Yes, I realize that most
other processors will also proabably need to be overniriden to work with any
differant whitespace normalization - but I'm okay with that.
As pointed out in #150, some processors have the tab length hardcoded in
regexes. I'm willing to accept a working patch that fixes that - and keeps
the regexes easy to override in a subclass (the provded patch moved them
inside the __init__ method - which is not so easy to override in a subclass)).
However, that is about the only additional change I'm willing to consider for
this issue.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Partial fix for #183. This has the same effect on empty lines in code blocks
as not using the html processor at all (which was eating some of the missing
newlines as reported in issue #183).
By doing `rsplit('\n\n')` the third newline (in each set of three) always ends
up at the end of a block, rather than the begining - which it less of an issue
for the html processor.
Also updated tests to indicate final intended output, although they do not fully
pass yet.
|
|
|
|
|
| |
Also refactored the reference preprocessor to make this a little easier to
implement. Regex does more now.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
rawhtml blocks. All tests pass again.
|
| |
|
| |
|
| |
|
|
|
|
| |
raw html parser. Fixed a related but I found while debugging this as well. Also added tests for both.
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
if they desire.
|
| |
|
|
|
|
| |
Fixes Ticket 39. NOTE: I did not add a seperate extension which only adds this feature - it is only available as part of 'extra'.
|
|
|
|
| |
treatment if raw <div>s with multiple line breaks - they no longer automagicly process their content as markdown. This matches other implementations. Finished rest of code for use by an extension - to be added later.
|
|
|
|
|
|
| |
now - allowing various arbitrary stuff (like x/html to be included without breaking the rawhtml parser.
Although currently unused, the code also provides the parsed attributes as a dict. Should be useful for adding support for parsing markdown text within rawhtml in an extension.
|
|
|
|
| |
inside raw <pre> tags.
|
|
|
|
| |
into a seperate block if it is a block tag. Inline tags are left in the block for the inline pattern as they should be.
|
|
|