aboutsummaryrefslogtreecommitdiffstats
path: root/tests
Commit message (Collapse)AuthorAgeFilesLines
...
* Issue #368: Fix Markdown in raw HTML stops workingfacelessuser2014-11-192-3/+24
| | | | | | | 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.
* Issue #365 Bold/Italic nesting fixfacelessuser2014-11-172-1/+7
| | | | | | | | | | | 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.
* Make TestCodeHilite tests working with Pygments 2.0rc1.Dmitry Shachnev2014-11-041-9/+5
| | | | Fixes #361.
* Fix tail out of order issuefacelessuser2014-10-182-1/+4
| | | | | | | | | | | | 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.
* Better nested STRONG EM support.Waylan Limberg2014-09-262-0/+41
| | | | | | | | | 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.
* Fix the lost tail issue in inlineprocessors.facelessuser2014-09-261-0/+14
| | | | | | 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.
* Added a temp workwround for deprecated short ext names.Waylan Limberg2014-09-251-9/+6
| | | | | | | | | | | | 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.
* Fixed TOC Option parsing.Waylan Limberg2014-09-251-1/+14
| | | | | | 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.
* Code Blocks must always be AtomicStringsWaylan Limberg2014-09-082-2/+11
| | | | | | | | | | | | | | | | | | 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.
* Mark special treatment of extension names as PendingDeprecationWaylan Limberg2014-08-292-21/+15
| | | | | | | | | | | | | | | | | 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.
* Refactored tests to no longer pass configs to names extensions.Waylan Limberg2014-08-291-10/+19
| | | | | `'path.to.module(option=value'` => `path.to.module.Class(option='value')` This is in anticipation of #335
* More updates to test configs.Waylan Limberg2014-08-294-2/+24
| | | | | | | | | | | | | | 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 extension tests now use python dot notation.Waylan Limberg2014-08-294-65/+67
| | | | | | | | | | 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.
* Allow named extensions to specify the Class NameWaylan Limberg2014-08-271-2/+15
| | | | | | | | | | | | | | | | | | 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-8/+17
| | | | | | | | | | | | | 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.
* Added some inline pattenr tests.Waylan Limberg2014-08-259-3/+22
| | | | | | | | | 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.
* Fixed a bug in markdown.util.parseBoolValueWaylan Limberg2014-08-251-0/+5
| | | | | A couple scenarios with "None" were previously not accounted for. Also updated tests which guives us 100% for markdown/util.py
* Add test of unsafe HTML in stash with safe_mode='excape'Waylan Limberg2014-08-251-0/+20
| | | | This should give us 100% coverage of postprocessors.py.
* Added `--extension_configs` option to the CLI.Waylan Limberg2014-08-221-0/+141
| | | | | | | | | | 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.
* 'http://packages.python.org/Markdown/' => ↵Waylan Limberg2014-08-212-10/+10
| | | | 'https://pythonhosted.org/Markdown/'. The former redirects to the latter anyway. Might as well point to the actual destination.
* Updated generate code for tests refactor. Related to #333.Waylan Limberg2014-08-211-3/+3
|
* Fix a typo in testing refactor. Related to #333Waylan Limberg2014-08-201-1/+1
|
* Refactored test framework to use YAML config files rather than INI. Fixes #333.Waylan Limberg2014-08-2017-212/+244
|
* Renamed 'smart_substitutions' option to 'substitutions'. Fixed a typo.Martin Altmayer2014-08-151-2/+2
|
* Added test for the new 'smart_substitutions' feature of Smarty extension.Martin Altmayer2014-08-141-0/+33
|
* Fixed an old typo in the smarty extension and added a test case.Martin Altmayer2014-08-112-1/+3
|
* Fixed silly typo. Relates to #325.Waylan Limberg2014-08-011-1/+1
|
* Ensure Extension.getConfigInfo Test always passesWaylan Limberg2014-08-011-2/+3
| | | | | Dicts don't preserve order but still will be equal while lists of tuples always preserve order. When we use a dict to create a list of tuples, the results are unpredictable - especially for a equality test. so we need to compare dicts, not lists. Related to #325
* Update extensions for Extension.__init__ refactorWaylan Limberg2014-07-311-16/+21
| | | | | | | | | | | | | | | | | 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).
* Refactor markdown.extensions.Extension.__init__()Waylan Limberg2014-07-291-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As pointed out in #325, setting up Extension configs is kind of a mess. Some places pass a list of tuples on initialization, others a dict. And sometimes they're passed as an arg, othertimes a kwarg. Addiitonaly, the docs are just as inconsistant. This refactor addresses all those sinerios with tests included. The existing extensions still need refactored. But the fact that their tests still pass means we havn't broken third party extensions either. This refactor also introduces a new API, which is the prefered method going forward. All docs should be updated to match. Whereas previously one might do: ```python MyExtension(configs={'key': 'foo', 'otherkey': 'bar'}) ``` This can now be done: ```python MyExtension(key='foo', otherkey='bar') ``` Of course, the old way still works for backward compatability. But that means the `configs` keyword has special status and cannot be used for another purpose.
* Add tests of markdown.extensions.ExtensionWaylan Limberg2014-07-111-0/+23
|
* 100% test coverage of admonitionsWaylan Limberg2014-07-102-0/+2
|
* smarty: add support for angled quotesDmitry Shachnev2014-06-193-1/+6
| | | | See <http://en.wikipedia.org/wiki/Guillemet>.
* Add failing unit test for smarty: ellipsis before close double quote ↵Lawrence Kesteloot2014-05-312-0/+3
| | | | generates opening double quote.
* Merge pull request #311 from mitya57/masterWaylan Limberg2014-05-261-1/+1
|\ | | | | Make smarty extension work together with attr_list
| * Add smarty to extensions for attr_list testDmitry Shachnev2014-05-061-1/+1
| | | | | | | | To make it easier to notice (and fix) the failure.
* | Fix issue308 and fix (unrelated) failure to break out of nest loop.ryneeverett2014-05-212-1/+14
|/
* Skip a weird PHP test.Waylan Limberg2014-04-201-0/+4
| | | I can't make out what this PHP test is trying to accomplish. From my point of view, our output is fine. So we skip this test.
* No assertIs in Python 2.6. Fixes #294Waylan Limberg2014-04-201-1/+1
|
* Add a (failing) test for Smarty extension.Dmitry Shachnev2014-02-132-1/+3
|
* Fix some tests failuresDmitry Shachnev2014-02-121-1/+1
|
* Merge branch 'master' of github.com:waylan/Python-MarkdownWaylan Limberg2014-01-123-0/+25
|\
| * Merge pull request #267 from ryneeverett/attr_list-tablesWaylan Limberg2014-01-113-0/+25
| |\ | | | | | | tables and attr_list compatibility
| | * tables_and_attr_list testryneeverett2014-01-113-0/+25
| | |
* | | Improved multiline comment parsing.Waylan Limberg2014-01-124-8/+52
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #257 and slightly alters comment parsing behavior. Unlike self-closing tags, a comment can contain angle brackets between the opening and closing tags. The greaterthan angle bracket at the end of the first block should not be mistaken for closing the comment. Need to actually check for a comment closing tag (`-->`). If one if not found, then the comment keeps going (to the end of the document if nessecary) just like in HTML. That last bit is a slight change from previous behavior, but should be unsurprising as that's how broswers parse html comments. And as far as I can tell, more implementations follow this behavior than any other. The ones that don't seem to be all over the place.
* | No longer percent encode spaces in urls.Waylan Limberg2014-01-092-3/+3
| | | | | | | | | | | | | | | | | | | | | | The current implementation was wrong as it also percent encoded query strings (which should be plus encoded) and calling urllib.quote on the path (and urllib.quote_plus on the query string) assumes the url is not already encoded. What if the document author pasted a url that was already encoded? She probably did not intend for `%20` to become `%2520`. Or did she? It is now clear to me why many implementation do nothing to urls. Just pass them though as-is. To bad if they are not valid HTML. HTML authors have to encodee their own urls, so I guess markdown authors have to as well.
* | Only escape ESCAPED_CHARS.Waylan Limberg2014-01-092-0/+24
| | | | | | | | | | | | Leave all other chars prefaced by a backslash alone. Fixes #242. Not sure why I thought that I needed to add another backslash. Thanks for the report and the test case @mhubig.
* | Address various depreciated APIs in PythonWaylan Limberg2014-01-081-4/+4
| | | | | | | | | | This mostly revolves around old APIs for ElementTree, but includes a few others as well. Fixes #254. Thanks for the report.
* | Merge pull request #274 from ajdavis/highlight-linesWaylan Limberg2014-01-071-0/+84
|\ \ | | | | | | Add feature for emphasizing some lines in a code block.
| * | Allow single as well as double quotes for hl_lines.A. Jesse Jiryu Davis2014-01-071-15/+19
| | |
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-14 07:01:53 +0000