| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
In addition to checking the spelling in our documentation, we are now also checking the spelling of the README.md and similar files as well as comments in our Python code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are small typos in:
- docs/extensions/fenced_code_blocks.md
- docs/extensions/meta_data.md
- markdown/extensions/codehilite.py
- markdown/extensions/footnotes.py
- tests/test_legacy.py
Fixes:
- Should read `delimiters` rather than `deliminators`.
- Should read `shebang` rather than `sheband`.
- Should read `processing` rather than `proccesing`.
- Should read `backslash` rather than `blackslash`.
Signed-off-by: Tim Gates <tim.gates@iress.com>
|
| |
|
|
|
|
|
|
|
|
| |
* Add an extra option `lang_str` to pass the language of the code block
to the specified Pygments formatter.
* Include an example custom Pygments formatter in the documentation
that includes the language of the code in the output using the new option.
Resolves #1255.
|
|
|
|
|
| |
This adds configuration support for using a custom Pygments formatter,
either by giving the string name, or a custom formatter class (or
callable).
|
|
|
|
|
|
|
|
|
| |
This fixes a bug where any subsequent highlighted block with codehilite
would result in the omission of the style setting, because it was popped
off the dict. It would then fall back to pygments_style 'default' after
the first block.
Fixes #1240
|
| |
|
|
|
| |
Fixes #1156.
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we'd unescape both `&gt;` and `>` to the same
string because we were running the & => & replacement first.
By changing the order of this replacement, we now convert:
`&gt; >` => `> >`
as expected.
Fixes #988.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add `language-` prefix to output when syntax highlighting is
disabled for both codehilite and fenced_code extensions.
* Add `lang_prefix` config option to customize the prefix.
* Add a 'pygments' env to tox which runs the tests with Pygments
installed. Pygments is locked to a specific version in the env.
* Updated codehilite to accept any Pygments options.
* Refactor fenced code attributes.
- ID attr is defined on `pre` tag.
- Add support for attr_list extension, which allows setting arbitrary
attributes.
- When syntax highlighting is enabled, any pygments options can
be defined per block in the attr list.
- For backward compatibility, continue to support `hi_lines` outside
of an attr_list. That is the only attr other than lang which is allowed
without the brackets (`{}`) of an attr list. Note that if the brackets
exist, then everything, including lang and hl_lines, must be within
them.
* Resolves #775. Resolves #334. Addresses #652.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed spellings :
1. shebang
2. identification
Added 'the' before 'said'
Fixed vertical line column size to 79
Fixed failing tests : Removed trailing spaces
|
|
|
|
|
|
|
| |
* Python syntax upgraded using `pyupgrade --py3-plus`
* Travis no longer uses `sudo`. See https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration
See #760 for Python Version Support Timeline and related dicussion.
|
|
|
| |
Pygments added the `wrapcode` option in version 2.4. Users need to have 2.4+ installed to see the change. However, as earlier versions accepted arbitrary keywords passed to the HTMLFormatter, no error will be raised if the user has an older version of Pygments installed.
|
| |
|
|
|
|
|
| |
Fixes #725
|
|
|
|
|
|
| |
In the past, most of the config was defined using globals. Today all of
the config is held on the class instance. Therefore, the `md_globals`
parameter is no longer necessary.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, instances of the Markdown class were represented as any one
of 'md', 'md_instance', or 'markdown'. This inconsistency made it
difficult when developing extensions, or just maintaining the existing
code. Now, all instances are consistently represented as 'md'.
The old attributes on class instances still exist, but raise a
DeprecationWarning when accessed. Also on classes where the instance was
optional, the attribute always exists now and is simply None if no
instance was provided (previously the attribute wouldn't exist).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All processors and patterns now get "registered" to a Registry.
Each item is given a name (string) and a priority. The name is for
later reference and the priority can be either an integer or float
and is used to sort. Priority is sorted from highest to lowest. A
Registry instance is a list-like iterable with the items auto-sorted
by priority. If two items have the same priority, then they are
listed in the order there were "registered". Registering a new
item with the same name as an already registered item replaces
the old item with the new item (however, the new item is sorted by
its newly assigned priority). To remove an item, "deregister" it by
name or index.
A backwards compatible shim is included so that existing simple
extensions should continue to work. DeprecationWarnings will
be raised for any code which calls the old API.
Fixes #418.
|
|
|
|
|
|
|
|
| |
In the past Markdown used to pass extension config settings to the
Extension class via a positional argument named `config`. That was
deprecated in 2.6 in favor of using keyword arguments (`**kwargs`).
Support has been completely dropped. Only keyword arguments are
accepted.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #601. Merged in 6f87b32 from the md3 branch and did a lot of cleanup.
Changes include:
* Removed old docs build tool, templates, etc.
* Added MkDocs config file, etc.
* filename.txt => filename.md
* pythonhost.org/Markdown => Python-Markdown.github.io
* Markdown lint and other cleanup.
* Automate pages deployment in makefile with `mkdocs gh-deploy`
Assumes a git remote is set up named "pages". Do
git remote add pages https://github.com/Python-Markdown/Python-Markdown.github.io.git
... before running `make deploy` the first time.
|
|
|
| |
Extend the language regex to match things like 'C#' and 'VB.Net'.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
'https://pythonhosted.org/Markdown/'. The former redirects to the latter anyway. Might as well point to the actual destination.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #325. All extensions can now accept a dict of configs or
**kwargs, not just a list of tuples. Third party extensions may want
to follow suite. Extensions may only accept keyword arguments
in the future. These changes still need to be documented.
A couple things of note:
The CodeHilite extension previously issued a DeprecationWarning
if the old config key `force_linenos` was used. With thins change,
a KeyError will now be raised.
The `markdown.util.parseBoolValue` function gained a new argument:
`preserve_none` (defaults to False), which when set to True, will
pass None through unaltered (will not convert it to False).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
A code blocked headed by “:::python{1,3}” now emphasizes the first and third lines. With fences enabled, ```python{1,3} has the same effect.
|
|
|
|
| |
It was previously marked pendingdeprecation in v2.3. Now deprecated.
|
|
|
|
|
|
|
|
|
| |
A `from __future__ import ...` statement must go after any docstrings;
since putting them before the docstring means the docstring loses its
magic and just becomes a string literal. That then causes a syntax
error if there are further future statements after the false docstring.
This fixes issue #203, using the patch provided by @Arfrever.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #148. The "force_linenos" config setting of the CodeHilite extension has been
marked as Pending Deprecation and a new setting "linenums" has been added to
replace it. See documentation for the [CodeHilite Extension] for an explaination
of the new "linenums" setting. The new setting will honor the old "force_linenos"
if it is set, but it will raise a PendingDeprecationWarning and will likely be
removed in a future version of Python-Markdown.
[CodeHilite Extension]: extensions/codehilite.html
|
| |
|
|
|
|
| |
homepage).
|
|
|
|
| |
first line of a code block for codehilite to recognize it.
|
|
|
|
|
|
|
|
| |
The footnotes treeprocessor must be the first one run so that all others,
including codehilite's, can run on the contents of the footnote div which is
created and inserted by the footnotes treeprocessor.
Thanks to startling for the report.
|
|
|
|
| |
closes #24
|
| |
|
|
|
|
| |
configs. No more self.config['name'][0] weirdness anymore.
|
|
|
|
| |
happen every time a block is highlighted. Not sure why I didn't do it this way to begin with.
|
|
|
|
| |
simpler markup which should allow for the use of JavaScript Highlighting libraries. In other words, no pygments like <div> and no <ol> for line numbering. Just a <pre><code> block with classes assinged to them. If people want fancier stuff, they can use JavaScript or create their own extension.
|
|
|
|
| |
default configs.
|