| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
The smart_strong extension has been removed and its behavior is now the
default (smart em and smart strong are the default). The legacy_em
extension restores legacy behavior.
This completes the removal of keywords. All parser behavior is now modified
by extensions, not by keywords on the Markdown class.
|
|
|
|
|
|
| |
If you have existing documents that use the legacy attributes format,
then you should enable the legacy_attrs extension for those documents.
Everyone is encouraged to use the attr_list extension going forward.
|
|
|
|
|
|
|
|
|
|
| |
The 'build' command never should have called 'build_docs'. It can
confuse users:
https://stackoverflow.com/questions/28387828/folders-installed-by-python-markdown
In fact, I have always run 'build_docs' seperately when I actually need to
build the docs. It serves no useful purpose as a subcommand of 'build'.
|
|
|
|
|
|
|
|
| |
The 'bin/markdown_py' script has been replaced with a 'markdown' entry point
and 'run_tests.py' with a 'mdtests' entry point.
The makefile uses 'python -m markdown.test' rather than 'mdtests' so it can run
even if the package is not installed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All previously supported methods of loading an extension given a string
name have now been replaced with entry points. Extension classes must be
registered as entry points in the 'markdown.extensions' group to support
string names. The old module-level 'makeExtension' function is no longer
needed. In fact, multiple extensions could be defined in one module
and still use string names if entry points are defined pointing to
each Extension subclass.
All of the build-in extensions are now registered with names that
mimic their paths (using dot notation). That may change in the future.
It is expected that all extensions will use short names. We may support
both ('extra' & 'markdown.extensions.extra') in the interim.
Also, all extension configs must now be dicts. Support for a list
of tuples has been removed.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
__version__ is now in __init__.py (as is should be) and the core is
defined in core.py. Other than version, __init__.py is just a dummy
which imports the pieces we make public.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now use importlib which means we no longer support Python 2.6.
Also, this refactor properly imports third party extensions which reside
at the root of PYTHONPATH. Previously, either `markdown.extensions.` or
`mdx_` would be appended to any extension name that did not contain a
dot, which required third party extensions to either be in submodules or
use the old `mdx_` naming convention.
This commit is also in preperation for #336. It will now be much easier to
deprecate (and later remove) support for the old ways of handling extension
names.
|
|
|
|
| |
'https://pythonhosted.org/Markdown/'. The former redirects to the latter anyway. Might as well point to the actual destination.
|
|
|
|
| |
and use it in our docs
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
so that there's no text breakage on PyPI page
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
The documentation uses features of Python-Markdown that are not supported on
GitHub and it's better to get a source view of the docs anyway. For example,
that way comments and bug reports can reference a specific line of a file.
Of course, it makes sense for Github to render the README, so that is left
with the `.md` file extension.
|
| |
|
|
|
|
|
|
| |
This is not a full Sphinx implementation. Just a limited implementation
which converts our markdown source filed to work with the default css for
Sphinx so it looks like Pythons docs.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
the file system.
|
| |
|
| |
|
|
|
|
| |
editors on the console. Let's keep lines under 80 characters in length.
|
|
|
|
| |
build_docs would be the one that wasn't 2to3'ed, thus causing a syntax error).
|
|
|
|
| |
docs. Still need to add the data to the docs themselves. That will come when I update the docs.
|
|
|
|
| |
still does not install docs on the system. It just writes html to the temp build dir.
|
|
|
|
| |
docs (should) now validate as xhtml - assuming they parse correctly. I suspect the docs need some updating though.
|
|\ |
|
| |
| |
| |
| | |
and 3.x in the setup script. Now the script actually can run 2to3 automaticaly when run under Python 3.x. Thanks for the report Virgil Dupras.
|