diff options
| author | Waylan Limberg <waylan@gmail.com> | 2013-03-18 23:48:16 -0400 |
|---|---|---|
| committer | Waylan Limberg <waylan@gmail.com> | 2013-03-18 23:48:16 -0400 |
| commit | 0f548dafad6a58bf6ef3b13dc9a058abf53a8a21 (patch) | |
| tree | 6c91f1094bb72976349b22f699d1a7c49fd8bdb3 /docs | |
| parent | dea54777a244c6593314dcd7b365eb7addbc8c99 (diff) | |
| download | markdown-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')
0 files changed, 0 insertions, 0 deletions