| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not sure this is the best way to go, but it works. I'm not crazy about
running the spellcheck against the built docs, but aspell has a builtin
option to easily ignore everything in `<code>` tags which greatly simplfies
things.
I looked at Doug Hellmans' sphinxcontrib-spelling package which does
something similar for Sphinx. However, as Sphinx uses rST and the rST
parser outputs a parse tree, Doug is essentially taking that parse tree
and running the spellcheck on the appropriate parts (skipping code, etc.).
He did a nice [writeup][5] of his development process if you are interested.
As Python-Markdown's parse tree is represented as HTML (through ElementTree)
I would have to use HTML anyway. And [PyEnchant][2] doesn't currently have
good support for HTML. So I used [aspell][3], with inspiration from the
[git-spell-check][4] hook.
[1]: http://sphinxcontrib-spelling.readthedocs.org/en/latest/index.html
[2]: https://pythonhosted.org/pyenchant/
[3]: http://aspell.net/
[4]: https://github.com/mprpic/git-spell-check
[5]: http://doughellmann.com/2011/05/26/creating-a-spelling-checker-for-restructuredtext-documents.html
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes #386. I'm doing this against my better judgement. The only reason is
that I'm using the HTML format suggested by the HTML5 Spec and will simply
not consider any alternate output. If a JavaScript library requires something
else, to bad. I don't care. That library should support the format
suggested by the spec or I'm not interested in it. If you want something else
then you can create your own extension which does whatever you want.
|
|
|
|
|
|
|
|
|
| |
Also checked for `None` so the existing extensions will at least still work.
Of course, that code all gets deleted with the next release and things will
break if extension authors do not update their code. Hope they test there
code with each release and check for warnings.
Also added a note to the release notes.
|
|
|
|
|
|
| |
`makeExtension` is the module level function defined in an extension,
not `extendMarkdown`, which is the method you override on the Extension class.
Do'h. Thanks for catching this @mitya57.
|
| |
|
|
|
|
|
|
|
|
|
| |
I need to remember this is a lib first and not configure logging from within
the lib. Also, from the script we are now actually displaying deprecation
warnings. For some reason I don't understnad deprecation warnings are hidden
by default in Python. And who remembers to run Python with the `-Wd` flag
every time they upgrade a lib just to make sure there's no new deprecations?
Fixes #384.
|
|\
| |
| | |
Fix typo in release-2.6.txt
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
This should make it easier to install test deps even when not using tox.
|
| |
|
|
|
|
|
|
| |
Mostly just code cleanup so it reads better. Renamed a few internal things.
I didn't write this extension originally so most of this would have been
done a long time ago. I just havn't touched this code much till now.
|
|\ |
|
| |\
| | |
| | | |
Fix a small typo
|
| |/ |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the Table of Contents Extension instead. The HeaderId Extension will
raise a PendingDeprecationWarning.
The last few features of the HeaderID extension were mirgrated to TOC
including the baselevel and separator config options. Also, the
marker config option of TOC can be set to an empty string to disable
searching for a marker.
The `slugify`, `unique` and `stashedHTML2text` functions are now defined
in the TOC extension in preperation for the HeaderId extension being
removed. All coresponding tests are now run against the TOC Extension.
The meta-data support of the HeaderId Extension was not migrated and no plan
exists to make that migration. The `forceid` config option makes no sense in
the TOC Extension and the only other config setting supported by meta-data
was the `header_level`. However, as that depends on the template, it makes
more sense to not be defined at the document level.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes #380. The TOC replacement is now seperate from building the
TOC, which allows us to iter through the doc in order rather than
with the non-order-preserving interparent pethod. This is almost a
complete refactor of the run method. Also cleaned up the config stuff.
Thanks to @colewerner for the report and test case.
|
|\
| |
| |
| |
| | |
Conflicts:
tests/test_extensions.py
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, we only added the toc attribute (md.toc) if no Marker was
found within the document. However, that has caused framworks to do things
like force insert a marker, run convert, then extract the toc from the
body of the document. This is much cleaner. And if the user wants to add
the toc to the document also, they still can.
|
| |
| |
| |
| |
| |
| | |
Now, whenever the TOC extensiuon is loaded, the Markdown class instance
will always have a toc attribute (md.toc). Calling md.reset() will also
reset the toc attribute which defaults to an empty string.
|
| | |
|
|/
|
|
|
|
| |
Now, whenever the TOC extensiuon is loaded, the Markdown class instance
will always have a toc attribute (md.toc). Calling md.reset() will also
reset the toc attribute which defaults to an empty string.
|
|
|
| |
Fixes #375. Explains the difference between returning None and returning a modified root element. Also makes the docs more consistent with the doc strings in the code.
|
|\
| |
| | |
Correct the documentation for the slugify function
|
| |
| |
| |
| |
| | |
The previous requirements are incorrect, the method needs to accept two
parameters.
|
|\ \
| | |
| | | |
flake8ify
|
|/ / |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
By default, this only supports YAML deliminators (`---`) and adds no
additional behavior. In other words, parsing is unchanged. However, with
the `yaml` option set, PyYAML will parse the metadata.
Thanks to @kernc for suggesting the idea and doing the work on this.
|
| | |
| | |
| | |
| | | |
We are ready to start adding/changing features now.
|
| |/ |
|
|/ |
|
| |
|
| |
|
|
|
|
|
| |
I've decided to go with longer lines in the tests. Also fixed a couple
errors with the previous cleanup.
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|\
| |
| | |
Issue #368: Fix Markdown in raw HTML stops working
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\|
| |
| | |
Fix issue #365 and #366
|
| |
| |
| |
| |
| |
| |
| |
| | |
This reworks the toc ordering to be done in a single pass with no
recursion. Very long documents with lots of headers can actually
exceed Python’s max recursion limit. By handling the toc ordering with
no recursion, large documents can no longer cause toc to fail with
recursion erros.
|
|/
|
|
|
|
|
|
|
|
|
| |
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 #361.
|
|
|
| |
Fixes #359. Thanks for the report @gremmie.
|