delta/python-markdown.git, branch 2.5.1-final github.com: waylan/Python-Markdown.git Upped version to 2.5.1 2014-09-26T22:35:55+00:00 Waylan Limberg waylan@gmail.com 2014-09-26T22:35:55+00:00 f0c5b71acbc02af60a33d67c59558bb513b25e74 Also removed an inacurate statement in the 2.5 release notes. 
Also removed an inacurate statement in the 2.5 release notes.
Run Meta after whitespace normalization 2014-09-26T14:44:24+00:00 Waylan Limberg waylan.limberg@icloud.com 2014-09-26T14:44:24+00:00 6bc119f3e048d18902ddfc66a9ffe9a47355e29a Fixes #343. Thanks for the report @AlexJF. 
Fixes #343. Thanks for the report @AlexJF.
Better nested STRONG EM support. 2014-09-26T14:29:48+00:00 Waylan Limberg waylan.limberg@icloud.com 2014-09-25T20:07:07+00:00 8358bb3c569026d9775859bcdbd2611fc9499420 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. 
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. 2014-09-26T14:27:48+00:00 facelessuser faceless.shop@gmail.com 2014-09-19T23:44:05+00:00 9082ed45deef99a0ff3c20aaa9f2c9b63e576838 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. 
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. 2014-09-26T02:26:07+00:00 Waylan Limberg waylan@gmail.com 2014-09-26T02:26:07+00:00 8f878c37dc3613b7279a0787bdcaf2d66b348d74 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. 
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. 2014-09-26T01:17:57+00:00 Waylan Limberg waylan@gmail.com 2014-09-26T01:17:57+00:00 39c8c1c64fe04bbde625b314386cb109b11527da 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. 
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.
Add 2.5 release date, and fix a typo. 2014-09-15T09:49:23+00:00 Dmitry Shachnev mitya57@gmail.com 2014-09-15T09:48:49+00:00 5fa6d0be20ec6392b265968e24a528b10128ede8 






Version 2.5-Final
2014-09-13T00:44:16+00:00

Waylan Limberg
waylan@gmail.com

2014-09-13T00:44:16+00:00

4ecbf34d7762d414bd6b027e37568693d05571fb












Deprecate positional args for markdownFromFile also.
2014-09-13T00:33:13+00:00

Waylan Limberg
waylan@gmail.com

2014-09-13T00:33:13+00:00

b41f2fad483c1fa20841b5657b112421b10ffc40












Code Blocks must always be AtomicStrings
2014-09-09T02:37:45+00:00

Waylan Limberg
waylan@gmail.com

2014-09-09T02:37:45+00:00

b91a37be0ab019fa1ee0b94014a6ed0c7ff5dbf5

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.





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.