| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
should say `pygmentize` not `pygmetize` on line 50
|
|
|
| |
Fixes #511. Thanks to @omiday for the report.
|
| |
|
| |
|
| |
|
|
|
| |
Improved the setup documentation when rendering Python code with Pygments and CodeHilite. Added a link to the Pygments CSS files and emphasized that not installing pygments does not cause an error message.
|
|
|
|
|
|
|
|
| |
As per [their blog post of the 27th April](https://blog.readthedocs.com/securing-subdomains/) ‘Securing subdomains’:
> Starting today, Read the Docs will start hosting projects from subdomains on the domain readthedocs.io, instead of on readthedocs.org. This change addresses some security concerns around site cookies while hosting user generated data on the same domain as our dashboard.
Test Plan: Manually visited all the links I’ve modified.
|
|
|
| |
Fixes #475.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation is not accurate when lazy_ol=False parameter is called.
The example shows the 'start' attribute to the first <li> tag. However, the attribute is in the <ol> tag:
>>> import markdown
>>> s = """
... 4. Apples
... 5. Oranges
... 6. Pears"""
>>> markdown.markdown(s, lazy_ol=False)
u'<ol start="4">\n<li>Apples</li>\n<li>Oranges</li>\n<li>Pears</li>\n</ol>'
The behaviour of the library is the correct one (https://developer.mozilla.org/fr/docs/Web/HTML/Element/ol), so the documentation need to be fixed, not the library.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The option was buggy. Rather than try to fix it, it is being removed.
This feeture should exist as a seperate extension. Fixes #390.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This format (using subheading rather than lists), allows for easy
linking to each individual section of the release notes. I think
we should sue this format going forward.
Also added an additional example to clarify the deprecation of the
special treatment of the 'mdx_' prefix for third party extensions.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 #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.
|
|/
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Fixes #359. Thanks for the report @gremmie.
|
|
|
|
| |
Also removed an inacurate statement in the 2.5 release notes.
|
| |
|
|
|
|
|
| |
Both `safe_mode` and `html_replacement_test` keywords are
pending deprecation, as are positional args. Closes #337.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The builtin extensions will no longer get special treatment and have
the path ("markdown.extensions.") appended . The same applies for
"mdx_" extensions. All names extension must provide the full path.
Fixes #336.
Also deprecating support for passing in extension config settings
as part of the string name. The extension_configs keyword should
be used instead. Fixes #335.
Also raising PendingDeprecationWarnings for positional args or the
"config" keyword on the Extension Class. Pass each setting as a
seperate keyword instead.
Docs and tests are updated. Still need to update extension API docs.
|
|
|
|
|
| |
This is in anticipation of #335. The reference and extension api docs still
need to be updated, but that will happen with change in the code.
|
|
|
|
|
|
| |
Except were "short names" are explained in the docs, all references
to the buitlin extensions now use `markdown.extensions.*` in
anticipation of #336.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you were to import the class like this:
from path.to.module import SomeExtensionClass
Then the named extension would be the string:
"path.to.module:SomeExtensionClass"
This should simplify loading extensions from the command line or
template filters -- expecially when multiple extensions are defined
in a single python module.
The docs still need updating. I'm waiting to update the docs after
implementing #335 and #336 as that will require a major refactor of
that section of the docs anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The `--extension_configs` option must point to a YAML or JSON file.
The contents of the file must parse to a Python Dict which will be
passed to the `extension_configs` keyword of the `markdown.Markdown`
class.
Also added tests for all of the CLI option parsing options and updated
documentation.
|
| |
|