| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This mostly revolves around old APIs for ElementTree, but includes a few
others as well. Fixes #254. Thanks for the report.
|
|
|
| |
spelling.
|
| |
|
|
|
|
|
|
|
|
|
| |
Setting output_format must happen after extensions are loaded. Only in that
way can an extension register a serializer so that it will then be available
to be used with the output_format keyword. A test has been added to avoid
this regression from happening again in the future.
Fixes #238, partially reverses commit 41cc055 and provides a better fix for
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Previously they contained colons - and they still do for HTML4 and XHTML.
Fixes #180.
|
|
|
|
| |
Fixes #184. Also delted some commented out code I missed in previous commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
My previous commit (d5a94c2) broke a few things badly. Unfortunately I failed
to run the complete test suite and didn't catch it. A bad regex was crashing
the test suite. Also cleaned up a few other odds and ends from previous work
on #183. Still loosing a few random empty lines in code blocks though.
I suspect this may also fix #188.
|
|
|
|
|
|
|
|
| |
Partial fix for #183. By preserving tabs at the start of empty lines in
code blocks, the parser will retain those empty lines. Still does not work
consistantly if the tab is missing!? Not sure why.
Also added tests.
|
|
|
|
|
|
| |
Partial fix for #183. Some lines are still being lost. When the processors are run, one line is lost. When their calling code is comments out (completely skiped) a line is still lost if more than 3 exist in a row.
Also need to add some tests for this.
|
|
|
|
|
| |
Also refactored the version info to force PEP 386 compliance and to avoid
the need to change the version in both the source and setup.py
|
|\
| |
| | |
Fixed pyflakes warnings
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Apparently, the `errors` keyword to encode was added in Python 2.7.
In previous versions, it was just a positional argument. This should
now work in all support versions.
Thanks to @Gamma3000 for assistance in working through this issue.
|
|/
|
|
|
|
|
|
| |
This is another try at this problem. The trick is geting code that works
with both Python 2 and Python 3. I think this does it. The only improvment
I can see now is to catch any errors and customize the error message to sugg
that the user set the environment variable PYTHONIOENCODING to the desired
encoding before calling the commandline script.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Python 2.x, if you write to stdout and stdout is piped
(for example: `python -m markdown foo.txt | less`), then
`sys.stdout.encoding` is `None` and an error is rasied.
Commit 1132f9e20cd7a5d6be809651f1034c44c32dbc0e was an attempt to
fix this, and it works in Python 2.x.
However, it does not work in Python 3.x, which does not exhibit this problem.
In fact, that fix actually breaks things in Python 3 whether the output
is piped or not. Additionaly, in Python 2.x, the fix is not needed if the
output is not being piped.
As we do not have a version specific issue, but an issue with
`sys.stdout.encoding`, we check for that to determine which way to go.
This way, the "right thing" *should* happen every time.
|
|
|
|
|
|
|
|
|
|
| |
Specificaly, `self.output_format` is defined and contains a string of the
output format used on the instance. This is more useful that an instance
of the searializer when determining alternate behavior elsewhere in the parser.
For example, see Issue #129.
Also cleaned up the error when an invalid format is provided. We now re-raise
the original error (with a custom message) rather than raising a new error.
|
|
|
|
|
|
|
| |
program.
In this case text should be encoded into the output encoding explicitly, because
sys.stdout.encoding is None, when piping data.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Note that you can still explicitly set 'enable_attributes' and that
value will be honored regardless of 'safe_mode'. However if 'safe_mode'
is on and 'enable_attributes' is not explicitly set, then
'enable_attributes' defaults to False.
|
| |
|
| |
|
|\
| |
| | |
Allow specifying the full module name for extensions.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this patch, it was possible to pass a list of extensions and
parameters to use when instantiating a new Markdown instance, but it was
not possible to give a full module name; the extension had to be a
submodule in markdown.extensions.
Now we allow giving a full module path, to make it easy to use custom
extensions which are not bundled within the markdown package. The
previous behaviour has been retained when there is no '.' in the
extension name.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Apparently, in Python3 stdin and stdout take str (unicode) not bytes.
This provides a solution that will work in both python 2 & 3.
|
|/ |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
[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.
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
xhtml1 searializers respectively.
|
|
|
|
| |
may be using them, so we should continue to support them. Also adjusted docs to encourage using keyword args only. However, if existing code was using positional args in previous versions, it should still work.
|