| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
New versions of Pygments insert <span></span> blocks in the beginning
of the generated output sometimes [1], so we need to remove those blocks
before doing the actual checking.
[1]: https://bitbucket.org/birkenfeld/pygments-main/commits/164574c13533
|
| |
|
|
|
|
|
| |
Now it should no longer print internal errors instead of intended ones
on Python 3.
Thanks to Maurice van der Pot for finding this fix.
|
| | |
|
| |
|
|
|
| |
The failure printed when self.assertTrue was used with str.startswith
did not show the string that was being searched.
|
| |
|
|
|
|
| |
Added pygments to test-requirements and updated codehiliting tests to
only test partial output as output differs depending on Pygments version.
Fixes #453
|
| | |
|
| |
|
|
|
|
| |
Drppoed the non-greedy quantifier from the end of the inlinePatterns as it
served no useful purpose and was actually (in very rare edge cases) causing
newlines to be dropped. FIxes #439. Thanks to @munificent for the report.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This should fix the remaining corner cases that can cause infinite
loops. Previous iterations did not account for scenarios where the
“end” index was less than the “start” index. If the “end” index is
ever less than or equal to the “start” index, the “end” will be
adjusted to to be “start” + 1 allow the full range to be extracted and
replaced.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The previous version did not work, and was incorrectly removed as part of
85ad18071d619251. In the new version, use lookbehind search for \w instead
of \b, so that it works.
Update the tests accordingly.
Fixes #399 (except parts that we can't fix). Thanks @gandaro for the report.
|
| |
|
|
|
| |
The option was buggy. Rather than try to fix it, it is being removed.
This feeture should exist as a seperate extension. Fixes #390.
|
| |
|
|
| |
Fixes #389. Thanks for the report @lazka.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
I need to remember this is a lib first and not configure logging from within
the lib. Also, from the script we are now actually displaying deprecation
warnings. For some reason I don't understnad deprecation warnings are hidden
by default in Python. And who remembers to run Python with the `-Wd` flag
every time they upgrade a lib just to make sure there's no new deprecations?
Fixes #384.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 #380. The TOC replacement is now seperate from building the
TOC, which allows us to iter through the doc in order rather than
with the non-order-preserving interparent pethod. This is almost a
complete refactor of the run method. Also cleaned up the config stuff.
Thanks to @colewerner for the report and test case.
|
| | |
|
| |
|
|
|
|
| |
Now, whenever the TOC extensiuon is loaded, the Markdown class instance
will always have a toc attribute (md.toc). Calling md.reset() will also
reset the toc attribute which defaults to an empty string.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
I've decided to go with longer lines in the tests. Also fixed a couple
errors with the previous cleanup.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Originally there was an infinite loop issue that was patched in issue
#308. Unfortunately, it was fixed all the way. This fix patches the
infinite loop fix to only add an offset to the `right_listindex` when
it is in a infinite loop scenario.
|
| |
|
|
|
|
|
|
|
|
|
| |
The logic for the current regex for strong/em and em/strong was sound,
but the way it was implemented caused some unintended side effects.
Whether it is a quirk with regex in general or just with Python’s re
engine, I am not sure. Put basically `(\*|_){3}` causes issues with
nested bold/italic. So, allowing the group to be defined, and then
using the group number to specify the remaining sequential chars is a
better way that works more reliably `(\*|_)\2{2}. Test from issue #365
was also added to check for this case in the future.
|
| |
|
|
| |
Fixes #361.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This issue was discovered when dealing with nested inlines. In
treeprocessors.py it was incorrectly handling tails. In short, tail
elements were being inserted earlier than they were supposed to be.
In order to fix this, the insertion index should be incremented by 1 so
that when the tails are inserted into the parent, they will be just
after the child they came from.
Also added a test in nested-patterns to catch this issue.
|
| |
|
|
|
|
|
|
|
| |
Fixes #253. Thanks to @facelessuser for the tests. Although I removed
a bunch of weird ones (even some that passed) from his PR (#342). For
the most part, there is no definitive way for those to be parsed. So
there is no point of testing for them. In most of those situations,
authors should be mixing underscores and astericks so it is clear
what is intended.
|
| |
|
|
|
|
| |
See #253. Prior to this patch, if any inline processors returned an element
with a tail, the tail would end up empty. This resolves that issue and will
allow for #253 to be fixed. Thanks to @facelessuser for the work on this.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As we chnaged the order in import trys for short names extensions
(no dot syntax), an extra test was added to the import code for the
occassion when a naming conflict exists. For example, if PyTables
is installed (module name is tables) and the user tries to use
the short name 'tables' instead of 'markdown.extensions.tables'.
Fixes #341.
Of course, this code will get ripped out when the old behavior is
fully deprecated.
|
| |
|
|
|
|
| |
The new option parser assumes bool values if the default is bool or
None. As the "title" option is not a bool value, it should default to an
empty string rather than None. Fixes #347.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #340. The "inline" TreeProcessor runs before the "prettify"
TreeProcessor, but the "smarty" TreeProcessor (wich is just another
instance of `InlineProcessor`) runs after the "prettify" TreeProcessor.
The problem was that the "prettify" TreeProcessor was losing the
AtomicString quality of the text of code blocks (any operation
on a string creates a new string. When that string is an AtomicString,
the new string must explicitly be declared as an AtomicString.
As the "prettify" TreeProcessor cleans up newlines on code blocks,
it was changing the AtomicString to a normal string. And as
`InlineProcessor` identifies what elements to skip solely by whether
the text is an AtomicString, the "smarty" instance was running on
code blocks.
Importantly, I added a test of code blocks and spans for smarty,
so this shouldn't break again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
`'path.to.module(option=value'` => `path.to.module.Class(option='value')`
This is in anticipation of #335
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The last few extensions were updated to accept dicts/**kwargs as configs and more
tests were updated. Also updated extra to actually accept configs.
Note that extra requires an extra level of dicts. First you need
to indicate tha the settings are for extra, then, which extension
extra wraps. I'm not crazy abount this, bit not sur ehow else to do it
without making all the configs a global attribute on the Markdown class
to that any extention can access any other extensions config settings.
I don't think we wnat to do that.
Also updated extra to use dot notation for the sub-extensions.
|
| |
|
|
|
|
|
|
|
|
| |
All named extensions now use python dot notation in the tests - including
all builtin extensions (eg: 'extra' => 'markdown.extensions.extra'). This
is in anticipation of #336.
Note there are a few tests (in the error tests) that will still need
updating, but not till we make the change as they will test for the
new error message.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
markdown/inlinepatterns.py is now at 99% coverage.
I have no idea why the two remaining lines are not not covered.
I it not clear to me under what circumstances this two if statements
would ever evaluate to True. I'm inclined to just remove them, but perhaps
there is an edge case I'm missing. I'll take another look later.
|
| |
|
|
|
| |
A couple scenarios with "None" were previously not accounted for.
Also updated tests which guives us 100% for markdown/util.py
|
| |
|
|
| |
This should give us 100% coverage of postprocessors.py.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
