aboutsummaryrefslogtreecommitdiffstats
path: root/docs/release-2.3.txt
diff options
context:
space:
mode:
authorWaylan Limberg <waylan@gmail.com>2013-03-18 23:48:16 -0400
committerWaylan Limberg <waylan@gmail.com>2013-03-18 23:48:16 -0400
commit0f548dafad6a58bf6ef3b13dc9a058abf53a8a21 (patch)
tree6c91f1094bb72976349b22f699d1a7c49fd8bdb3 /docs/release-2.3.txt
parentdea54777a244c6593314dcd7b365eb7addbc8c99 (diff)
downloadmarkdown-0f548dafad6a58bf6ef3b13dc9a058abf53a8a21.tar.gz
markdown-0f548dafad6a58bf6ef3b13dc9a058abf53a8a21.tar.bz2
markdown-0f548dafad6a58bf6ef3b13dc9a058abf53a8a21.zip
Ensure handleAttributes doesn't lose AtomicStrings.
Fixes #204. This was a real pain to debug. But I think the problem stemmed from the fact that the footnote extension inserted a etree link into the footnotes last p element. Then when inline patterns are run, the inline code in that p element is processed. Normally, code would be the first child found, but with the pre-existing link, that wasn't the case and the parser took a slightly differant path which would never be encountered in any other situation. It was this slightly differant path that made the lose of the AtomicString status of the inline code matter. Since any AtomicString (including inline code) doesn't need to be run though hanldeAttributes anyway, we can just skip over it and preserve the AtomicString. Whew!
Diffstat (limited to 'docs/release-2.3.txt')
0 files changed, 0 insertions, 0 deletions