| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
| |
Fixes #554.
|
|
|
| |
add . before `codehilite` to generate a proper css output (to reference the codehilite class)
|
|
|
| |
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.
|
| |
|