aboutsummaryrefslogtreecommitdiffstats
path: root/docs
Commit message (Collapse)AuthorAgeFilesLines
* GitHub/waylan => GitHub/Python-Markdown orgWaylan Limberg2017-08-1712-13/+13
|
* The location keyword of OrderedDict.add is not optional.Waylan Limberg2017-03-091-1/+1
| | | Fixes #554.
* command line (#517)Ben Petty2016-12-231-1/+1
| | | add . before `codehilite` to generate a proper css output (to reference the codehilite class)
* Spelling error (#516)Ben Petty2016-12-231-1/+1
| | | should say `pygmentize` not `pygmetize` on line 50
* Fox formatting of extension_configs example.Waylan Limberg2016-11-171-7/+3
| | | Fixes #511. Thanks to @omiday for the report.
* Up version to 2.6.72.6.7-finalWaylan Limberg2016-09-231-0/+2
|
* Fix a few spelling errors.Waylan Limberg2016-09-231-3/+3
|
* Additional improvements to Codehilite docs. Addesses concerns raised in #480.Waylan Limberg2016-06-061-18/+45
|
* added instructions for CodeHilite with PygmentsKristian Rother2016-06-061-8/+15
| | | 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.
* Convert readthedocs link for their .org -> .io migration for hosted projectsAdam Chainz2016-05-292-3/+3
| | | | | | | | 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.
* Added version 2.6.6 to change log.Waylan Limberg2016-05-251-0/+2
| | | Fixes #475.
* Fix lazy ordered list example in documentationsblondon2016-03-301-2/+2
| | | | | | | | | | | | | | | 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.
* Updated change_logWaylan Limberg2015-11-241-0/+2
|
* Upped to version 2.6.4.2.6.4-finalWaylan Limberg2015-11-061-0/+2
|
* Upped to version 2.6.3.2.6.3-finalWaylan Limberg2015-10-261-0/+2
|
* Updated change_log for 2.6.2.Waylan Limberg2015-04-201-0/+2
|
* fix broken documentation codeJakob Kramer2015-03-131-5/+5
|
* Upped version to 2.6.12.6.1-finalWaylan Limberg2015-03-081-0/+4
|
* Removed `yaml` option from meta-data extension.Waylan Limberg2015-03-082-20/+10
| | | | | The option was buggy. Rather than try to fix it, it is being removed. This feeture should exist as a seperate extension. Fixes #390.
* Upped version to 2.6 final2.6-finalWaylan Limberg2015-02-191-1/+1
|
* Cleaned up spelling (again).Waylan Limberg2015-02-181-4/+4
|
* Reformatted Release Notes for 2.6.Waylan Limberg2015-02-181-154/+188
| | | | | | | | | 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.
* Thorough spell check of the docs.Waylan Limberg2015-02-0728-429/+441
|
* Added a 'use_pygments' config option to CodeHilite.Waylan Limberg2015-02-052-1/+22
| | | | | | | | | 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.
* Upgraded to DeprecationWarning on ext `config` keyword.Waylan Limberg2015-02-051-9/+57
| | | | | | | | | 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.
* typo fixnikolas2015-01-281-1/+1
|
* Fix typo in release-2.6.txtnikolas2015-01-281-1/+1
|
* Add offical support for PyPy.Waylan Limberg2015-01-101-1/+6
|
* Clean up a few typos and formatting issues.Waylan Limberg2015-01-012-55/+51
|
* Merge branch 'master' of https://github.com/waylan/Python-MarkdownWaylan Limberg2015-01-011-1/+1
|\
| * Fix a small typoAlexander Artemenko2014-12-311-1/+1
| |
* | HeaderId Extension marked as Pending Deprecation.Waylan Limberg2015-01-013-34/+110
|/ | | | | | | | | | | | | | | | | | | | 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.
* Added first draft of 2.6 release notes.Waylan Limberg2014-12-305-6/+142
|
* Better docs of treeprocessor API.Waylan Limberg2014-12-291-3/+14
| | | 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.
* Merge pull request #378 from d0ugal/docs-fixWaylan Limberg2014-12-231-4/+5
|\ | | | | Correct the documentation for the slugify function
| * Correct the documentation for the slugify functionDougal Matthews2014-12-221-4/+5
| | | | | | | | | | The previous requirements are incorrect, the method needs to accept two parameters.
* | Add YAML support to Meta extensionKernc2014-11-301-6/+26
|/ | | | | | | | 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.
* Added 2.5.2 to changelog.Waylan Limberg2014-11-201-0/+2
|
* Updated nl2br example in docs.Waylan Limberg2014-10-281-1/+1
| | | Fixes #359. Thanks for the report @gremmie.
* Upped version to 2.5.12.5.1-finalWaylan Limberg2014-09-262-6/+5
| | | | Also removed an inacurate statement in the 2.5 release notes.
* Add 2.5 release date, and fix a typo.Dmitry Shachnev2014-09-152-2/+2
|
* Mark "Safe Mode" as pending deprecation.Waylan Limberg2014-09-013-25/+72
| | | | | Both `safe_mode` and `html_replacement_test` keywords are pending deprecation, as are positional args. Closes #337.
* Some docs cleanup.Waylan Limberg2014-08-297-60/+53
|
* Updated extension API docs for recent changes.Waylan Limberg2014-08-292-46/+70
|
* Mark special treatment of extension names as PendingDeprecationWaylan Limberg2014-08-293-27/+55
| | | | | | | | | | | | | | | | | 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.
* Code exampeles in extension docs now show best practices.Waylan Limberg2014-08-292-13/+14
| | | | | 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.
* Docs now use dot notation for all extensions.Waylan Limberg2014-08-2918-59/+52
| | | | | | Except were "short names" are explained in the docs, all references to the buitlin extensions now use `markdown.extensions.*` in anticipation of #336.
* Various tweaks to release notes.Waylan Limberg2014-08-271-34/+46
|
* Allow named extensions to specify the Class NameWaylan Limberg2014-08-271-0/+30
| | | | | | | | | | | | | | | | | | 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.
* Refactored extension importing.Waylan Limberg2014-08-271-1/+4
| | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-24 20:58:58 +0000