Menu
▾
▴
python-markdown-discuss
|
From: Blake W. <bw...@la...> - 2008-02-15 22:30:15
Attachments:
backtick.diff
|
(Apologies if any of you get this twice, I had a hiccup with my mail server.) (Uh, third time's a charm?) Looking at http://daringfireball.net/projects/markdown/syntax.php#backslash Markdown provides backslash escapes for the following characters: [...] ` backtick And yet, when I try it in (using markdown-1.6-py2.4.egg) ----------- >>> from markdown import markdown >>> x = "\\`This should not be in code.\\`" >>> print x \`This should not be in code.\` >>> print markdown( x ) <p>\<code>This should not be in code.\</code> </p> ----------- So I edit the code a little, as so (also attached): ----------- === modified file 'markdown.py' --- markdown.py 2008-02-15 21:28:18 +0000 +++ markdown.py 2008-02-15 21:28:30 +0000 @@ -944,9 +944,9 @@ self.prePatterns = [] - self.inlinePatterns = [ DOUBLE_BACKTICK_PATTERN, + self.inlinePatterns = [ ESCAPE_PATTERN, + DOUBLE_BACKTICK_PATTERN, BACKTICK_PATTERN, - ESCAPE_PATTERN, IMAGE_LINK_PATTERN, IMAGE_REFERENCE_PATTERN, REFERENCE_PATTERN, ----------- and that gives me: ----------- >>> from markdown import markdown >>> x = "\\`This should not be in code.\\`" >>> print x \`This should not be in code.\` >>> >>> print markdown( x ) <p>`This should not be in code.` </p> ----------- Which I believe is closer to the spec. Thanks, Blake. |
|
From: Yuri T. <qar...@gm...> - 2008-02-15 22:35:07
|
Thanks! On Fri, Feb 15, 2008 at 2:30 PM, Blake Winton <bw...@la...> wrote: > (Apologies if any of you get this twice, I had a hiccup with my mail server.) > (Uh, third time's a charm?) > > Looking at http://daringfireball.net/projects/markdown/syntax.php#backslash > Markdown provides backslash escapes for the following characters: > [...] > ` backtick > > And yet, when I try it in (using markdown-1.6-py2.4.egg) > > ----------- > >>> from markdown import markdown > >>> x = "\\`This should not be in code.\\`" > >>> print x > \`This should not be in code.\` > >>> print markdown( x ) > > <p>\<code>This should not be in code.\</code> > </p> > > > > ----------- > > So I edit the code a little, as so (also attached): > ----------- > === modified file 'markdown.py' > --- markdown.py 2008-02-15 21:28:18 +0000 > +++ markdown.py 2008-02-15 21:28:30 +0000 > @@ -944,9 +944,9 @@ > self.prePatterns = [] > > > - self.inlinePatterns = [ DOUBLE_BACKTICK_PATTERN, > + self.inlinePatterns = [ ESCAPE_PATTERN, > + DOUBLE_BACKTICK_PATTERN, > BACKTICK_PATTERN, > - ESCAPE_PATTERN, > IMAGE_LINK_PATTERN, > IMAGE_REFERENCE_PATTERN, > REFERENCE_PATTERN, > ----------- > > and that gives me: > ----------- > >>> from markdown import markdown > >>> x = "\\`This should not be in code.\\`" > >>> print x > \`This should not be in code.\` > >>> > >>> print markdown( x ) > > <p>`This should not be in code.` > </p> > > > > ----------- > > Which I believe is closer to the spec. > > Thanks, > Blake. > > > > === modified file 'markdown.py' > --- markdown.py 2008-02-15 21:28:18 +0000 > +++ markdown.py 2008-02-15 21:28:30 +0000 > @@ -944,9 +944,9 @@ > self.prePatterns = [] > > > - self.inlinePatterns = [ DOUBLE_BACKTICK_PATTERN, > + self.inlinePatterns = [ ESCAPE_PATTERN, > + DOUBLE_BACKTICK_PATTERN, > BACKTICK_PATTERN, > - ESCAPE_PATTERN, > IMAGE_LINK_PATTERN, > IMAGE_REFERENCE_PATTERN, > REFERENCE_PATTERN, |
|
From: Waylan L. <wa...@gm...> - 2008-02-16 00:07:16
|
Thanks for the report. However, this makes it imposable to represent the string of an escapes backtick "\`" in a code span. >>> import markdown >>> s = "`code with a \` in it`" >>> markdown(s) <p>`code with a ` in it\n<p> A double backtick won't work either. And yes, I realize that the doublebacktick should eliminate the need to escape, but what about when we are trying to represent markdown source in our document? >>> s = "`` code with a \` in it``" <p><code></code>code with a ` in it<code></code>\n</p> This highlights the problem. The string is being broken into two strings with a textnode containing the escaped backtick between. We can't run a pattern across two strings. The patterns code would need to be completely rewritten to fix that. Hmm, while typing this it occurred to me that we should be able to escape the escape character. I believe that presently, this would also create that textnode between two strings though. Maybe the the escape regex could be reworked. I'll see what I can do. On Feb 15, 2008 5:30 PM, Blake Winton <bw...@la...> wrote: > (Apologies if any of you get this twice, I had a hiccup with my mail server.) > (Uh, third time's a charm?) > > Looking at http://daringfireball.net/projects/markdown/syntax.php#backslash > Markdown provides backslash escapes for the following characters: > [...] > ` backtick > > And yet, when I try it in (using markdown-1.6-py2.4.egg) > > ----------- > >>> from markdown import markdown > >>> x = "\\`This should not be in code.\\`" > >>> print x > \`This should not be in code.\` > >>> print markdown( x ) > > <p>\<code>This should not be in code.\</code> > </p> > > > > ----------- > > So I edit the code a little, as so (also attached): > ----------- > === modified file 'markdown.py' > --- markdown.py 2008-02-15 21:28:18 +0000 > +++ markdown.py 2008-02-15 21:28:30 +0000 > @@ -944,9 +944,9 @@ > self.prePatterns = [] > > > - self.inlinePatterns = [ DOUBLE_BACKTICK_PATTERN, > + self.inlinePatterns = [ ESCAPE_PATTERN, > + DOUBLE_BACKTICK_PATTERN, > BACKTICK_PATTERN, > - ESCAPE_PATTERN, > IMAGE_LINK_PATTERN, > IMAGE_REFERENCE_PATTERN, > REFERENCE_PATTERN, > ----------- > > and that gives me: > ----------- > >>> from markdown import markdown > >>> x = "\\`This should not be in code.\\`" > >>> print x > \`This should not be in code.\` > >>> > >>> print markdown( x ) > > <p>`This should not be in code.` > </p> > > > > ----------- > > Which I believe is closer to the spec. > > Thanks, > Blake. > > > > === modified file 'markdown.py' > --- markdown.py 2008-02-15 21:28:18 +0000 > +++ markdown.py 2008-02-15 21:28:30 +0000 > @@ -944,9 +944,9 @@ > self.prePatterns = [] > > > - self.inlinePatterns = [ DOUBLE_BACKTICK_PATTERN, > + self.inlinePatterns = [ ESCAPE_PATTERN, > + DOUBLE_BACKTICK_PATTERN, > BACKTICK_PATTERN, > - ESCAPE_PATTERN, > IMAGE_LINK_PATTERN, > IMAGE_REFERENCE_PATTERN, > REFERENCE_PATTERN, > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Python-markdown-discuss mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss > > -- ---- Waylan Limberg wa...@gm... |
|
From: Blake W. <bw...@la...> - 2008-02-16 04:04:21
Attachments:
backtick.diff
|
Waylan Limberg wrote:
> Thanks for the report. However, this makes it imposable to represent
> the string of an escapes backtick "\`" in a code span.
Argh. :)
>>>> s = "`code with a \` in it`"
> A double backtick won't work either.
>>>> s = "`` code with a \` in it``"
> This highlights the problem.
Okay, I've gotten a little closer with the attached patch.
In [7]: print markdown.markdown( "`code with a \` in it`" ).strip()
<p><code>code with a ` in it</code>
</p>
In [8]: print markdown.markdown( "`` code with a \` in it``" ).strip()
<p><code>code with a ` in it</code>
</p>
In [9]: print markdown.markdown( "`` code with a \`` in it``" ).strip()
<p><code>code with a `` in it</code>
</p>
> The string is being broken into two
> strings with a textnode containing the escaped backtick between. We
> can't run a pattern across two strings. The patterns code would need
> to be completely rewritten to fix that.
I think that way would lead to madness. It seems like it might be
simpler if the escaping mechanism were just a simple function, that you
could call from a lot of places, many times per line.
> Hmm, while typing this it occurred to me that we should be able to
> escape the escape character. I believe that presently, this would also
> create that textnode between two strings though. Maybe the the escape
> regex could be reworked. I'll see what I can do.
I don't think it really fits in as a pattern, since it can happen
multiple times per line, and in the middle of other patterns. Perhaps
it should be on a lower level, i.e. in createTextNode, or something?
The worst part of that, I believe, is that it would mess up the parsing
of all the other patterns, since they'ld have to avoid breaking on, say,
\\` for the code case.
Hey, what if the escape character turned the following character into
its hex-escape, as a pre-transformation? Something along these lines:
In [4]: def hexesc(m):
...: return "&#x%x;" % ord(m.group(1))
...:
In [5]: re.sub( r"\\(.)", hexesc, "abc \\ def" )
Out[5]: 'abc   def'
and then take that string, and run it through the patterns?
Later,
Blake.
|
|
From: Blake W. <bw...@la...> - 2008-02-17 00:46:04
Attachments:
backtick.patch
|
Blake Winton wrote:
> Hey, what if the escape character turned the following character into
> its hex-escape, as a pre-transformation? Something along these lines:
> In [4]: def hexesc(m):
> ...: return "&#x%x;" % ord(m.group(1))
> ...:
>
> In [5]: re.sub( r"\\(.)", hexesc, "abc \\ def" )
> Out[5]: 'abc   def'
>
> and then take that string, and run it through the patterns?
Well, I started in on this, and I think I've got something that's at
least proof-of-concept material...
In [2]: print markdown.markdown( r"\``\`abc\``\`d&ef " ).strip()
<p>`<code>`abc`</code>`d&ef 
</p>
I'm sure there are bugs, (because it's software ;) and the duplication
of the unescape method is a little ugly, but hopefully someone more in
tune with the codebase can take the patch and make it pretty and more
correct. (One of the bugs I found before I sent this was that bare &s
weren't getting translated into & Fortunately, it was easy enough
to fix.)
For those who are interested, here's the explanation of the patch, hunk
by hunk:
----------------------
@@ -220,6 +220,10 @@
attrRegExp = re.compile(r'\{@([^\}]*)=([^\}]*)}') # {@id=123}
def __init__ (self, text) :
+ def hexunesc(m):
+ return "%c" % chr(int(m.group(0)[3:-1],16))
+ unescapeChars = r"&#x[0-9A-Fa-f]+;"
+ text = re.sub( unescapeChars, hexunesc, text )
self.value = text
def attributeCallback(self, match) :
----------------------
This is TextNode's init, where it is being passed escaped characters,
and so it unescapes them.
----------------------
@@ -488,8 +492,8 @@
Also note that all the regular expressions used by inline must
capture the whole block. For this reason, they all start with
-'^(.*)' and end with '(.*)!'. In case with built-in expression
-Pattern takes care of adding the "^(.*)" and "(.*)!".
+'^(.*)' and end with '(.*)$'. In case with built-in expression
+Pattern takes care of adding the "^(.*)" and "(.*)$".
Finally, the order in which regular expressions are applied is very
important - e.g. if we first replace http://.../ links with <a> tags
----------------------
Just some typo fixes I thought I'ld throw in there.
----------------------
@@ -518,9 +522,8 @@
+ (NOBRACKET+ r'\])*'+NOBRACKET)*6
+ NOBRACKET + r')\]' )
-BACKTICK_RE = r'\`([^\`]*)\`' # `e= m*c^2`
-DOUBLE_BACKTICK_RE = r'\`\`(.*)\`\`' # ``e=f("`")``
-ESCAPE_RE = r'\\(.)' # \<
+BACKTICK_RE = r'`([^`]*)`' # `e= m*c^2`
+DOUBLE_BACKTICK_RE = r'``(.*?)``' # ``e=f("`")``
EMPHASIS_RE = r'\*([^\*]*)\*' # *emphasis*
STRONG_RE = r'\*\*(.*)\*\*' # **strong**
STRONG_EM_RE = r'\*\*\*([^_]*)\*\*\*' # ***strong***
----------------------
Since we are handling escapes at a different level, we don't need the
regex for them anymore. Also, ` isn't a special character in regexes,
so we don't need to \-escape it. Finally, I've made the double-backtick
regular expression non-greedy (by adding the ? in the (.*?), since I
think that ``abc`` def ``ghi`` should probably be two code blocks.
----------------------
@@ -540,16 +543,16 @@
IMAGE_REFERENCE_RE = r'\!' + BRK + '\s*\[([^\]]*)\]' # ![alt text][2]
NOT_STRONG_RE = r'( \* )' # stand-alone * or _
AUTOLINK_RE = r'<(http://[^>]*)>' # <http://www.123.com>
-AUTOMAIL_RE = r'<([^> \!]*@[^> ]*)>' # <me...@ex...>
-#HTML_RE = r'(\<[^\>]*\>)' # <...>
+AUTOMAIL_RE = r'<([^> \!]*@[^> ]*)>' # <me...@ex...>
+#HTML_RE = r'(\<[^\>]*\>)' # <...>
HTML_RE = r'(\<[a-zA-Z/][^\>]*\>)' # <...>
-ENTITY_RE = r'(&[\#a-zA-Z0-9]*;)' # &
+ENTITY_RE = r'(&[\#a-zA-Z0-9]*;)' # &
class Pattern:
def __init__ (self, pattern) :
self.pattern = pattern
- self.compiled_re = re.compile("^(.*)%s(.*)$" % pattern, re.DOTALL)
+ self.compiled_re = re.compile("^(.*?)%s(.*?)$" % pattern,
re.DOTALL)
def getCompiledRegExp (self) :
return self.compiled_re
----------------------
Fix the spacing on the comments for AUTOLINK and #HTML.
Also, since we're escaping things by turning them into F4; we also
need to make sure that pattern can't be entered by the user, so we
escape any &s into &, which means that entities entered by the user
will be (in escaped-form) &amp;
----------------------
@@ -700,7 +703,6 @@
el.setAttribute('href', mailto)
return el
-ESCAPE_PATTERN = SimpleTextPattern(ESCAPE_RE)
NOT_STRONG_PATTERN = SimpleTextPattern(NOT_STRONG_RE)
BACKTICK_PATTERN = BacktickPattern(BACKTICK_RE)
----------------------
We don't need the escape pattern, as mentioned above.
----------------------
@@ -767,6 +769,10 @@
@param html: an html segment
@returns : a placeholder string """
+ def hexunesc(m):
+ return "%c" % chr(int(m.group(0)[3:-1],16))
+ unescapeChars = r"&#x[0-9A-Fa-f]+;"
+ html = re.sub( unescapeChars, hexunesc, html )
self.rawHtmlBlocks.append(html)
placeholder = HTML_PLACEHOLDER % self.html_counter
self.html_counter += 1
----------------------
So, in the HtmlStash, we need to unescape things before we stash them,
because they won't be part of TextNodes (which is the other place that
does the unescaping).
----------------------
@@ -946,8 +952,7 @@
self.inlinePatterns = [ DOUBLE_BACKTICK_PATTERN,
BACKTICK_PATTERN,
- ESCAPE_PATTERN,
- IMAGE_LINK_PATTERN,
+ IMAGE_LINK_PATTERN,
IMAGE_REFERENCE_PATTERN,
REFERENCE_PATTERN,
LINK_ANGLED_PATTERN,
----------------------
We don't need the escape pattern. And fix the spacing on the IMAGE_LINK
while we're here.
----------------------
@@ -1043,6 +1048,14 @@
# Split into lines and run the preprocessors that will work with
# self.lines
+ def hexesc(m):
+ if m.group(1):
+ return "&#x%x;" % ord(m.group(1))
+ else:
+ return "&#x%x;" % ord('&')
+
+ escapeChars = r"\\([\\`*_{}\[\]()#+.!-])|&"
+ text = re.sub( escapeChars, hexesc, text )
self.lines = text.split("\n")
# Run the pre-processors on the lines
----------------------
And finally, in _transform, before we split into lines, we should
translate the various escape characters into their escaped form.
The regex limits the escape characters to the ones listed in
http://daringfireball.net/projects/markdown/syntax#backslash specifically:
\ backslash
` backtick
* asterisk
_ underscore
{} curly braces
[] square brackets
() parentheses
# hash mark
+ plus sign
- minus sign (hyphen)
. dot
! exclamation mark
and we also escape & (at the end of the regex), for reasons mentioned above.
Uh, thanks for reading this far. I hope it all made sense. Please let
me know if you found it helpful, or if I was totally wasting my time. ;)
Later,
Blake.
|
|
From: Waylan L. <wa...@gm...> - 2008-02-17 02:59:40
|
Blake, this is an interesting approach I hadn't thought of and I like it .
However, what about code blocks and spans in which the author had
included an escape sequence? When we run through the unescape code,
how do we know that it was an escaped character, not something
intentionally typed by the author that should be left alone? For
example:
The escape sequence for a backslash (`\\`) is: `\`.
Or is that why you also escape the `&`?
Either way, I was never particularly fond of the way markdown
currently handles escaping. I think your solution is much more elegant
and I'd prefer to use something very much like it.
However, I'm thinking that one of two things needs to happen:
1. The escaping needs to happen at the inline pattern level (or at
least right before/after them, perhaps in _handleInline), rather than
on the entire document. That eliminates the need to worry about
messing with code blocks and raw html.
2. Assuming the above concern is moot, the escaping and unescaping
should be pre and post processors respectively. Check the doc strings
on the latest in svn (see below) for TextPreprocessor (line 413) and
TextPostprocessor (line 945) which run on the entire document as a
single string rather than split lines.
I appreciate all your hard work on this. However, it would be helpful
if your diffs were against the latest in svn. There's been quite a few
changes since 1.6.
You can checkout from here:
svn co https://python-markdown.svn.sourceforge.net/svnroot/python-markdown
python-markdown
Which includes the test suite so you can check whether your breaking
anything else. Or if you don't have access to subversion, at least the
file markdown.py is available here:
http://python-markdown.svn.sourceforge.net/viewvc/python-markdown/markdown.py?view=markup
--
----
Waylan Limberg
wa...@gm...
|
|
From: Blake W. <bw...@la...> - 2008-02-17 04:05:58
|
Waylan Limberg wrote: > Blake, this is an interesting approach I hadn't thought of and I like it . Thanks! > When we run through the unescape code, > how do we know that it was an escaped character, not something > intentionally typed by the author that should be left alone? > Or is that why you also escape the `&`? Yup, that's exactly why I escape the &. > Either way, I was never particularly fond of the way markdown > currently handles escaping. I think your solution is much more elegant > and I'd prefer to use something very much like it. > > However, I'm thinking that one of two things needs to happen: > > 1. The escaping needs to happen at the inline pattern level (or at > least right before/after them, perhaps in _handleInline), rather than > on the entire document. That eliminates the need to worry about > messing with code blocks and raw html. Well, I think that escapes can happen (almost) anywhere, not just in inline patterns. (Unless inline patterns handle everything except code blocks...) Reading the documentation again, I'm not entirely sure why I believe that. Perhaps confirmation from Mr. Gruber is in order. Either way, though, I think that the other factor that kind of renders this moot is that any characters that get escaped will get unescaped on the way out, so it's as if we didn't do anything to them at all. We're just hiding them from the internal processors. And the internal processors can even pay attention to them if they want, since our mapping is consistent. (If you see "&#x[0-9a-zA-Z]+;", you know it's an escaped character. If you see "&", you know it was an &.) > 2. Assuming the above concern is moot, the escaping and unescaping > should be pre and post processors respectively. Check the doc strings > on the latest in svn (see below) for TextPreprocessor (line 413) and > TextPostprocessor (line 945) which run on the entire document as a > single string rather than split lines. Yeah, I could see that. Were the pre and post processors in 1.6 and I just missed them? As a side note, I'm running against 1.6, because that was what got installed when I typed "easy_install markdown". :) > I appreciate all your hard work on this. However, it would be helpful > if your diffs were against the latest in svn. There's been quite a few > changes since 1.6. Fair enough. I'll see when I next have some free time, and give that a try. > You can checkout from here: > svn co https://python-markdown.svn.sourceforge.net/svnroot/python-markdown > python-markdown > Which includes the test suite so you can check whether your breaking > anything else. Ah, I was wondering where that was... Okay, I've got a copy in my python 2.5 installation, and all the tests pass, so I should be good to go with my modifications, I believe. Thanks, Blake. |
|
From: Blake W. <bw...@la...> - 2008-02-17 04:19:32
|
Blake Winton wrote: > Waylan Limberg wrote: >> 1. The escaping needs to happen at the inline pattern level (or at >> least right before/after them, perhaps in _handleInline), rather than >> on the entire document. That eliminates the need to worry about >> messing with code blocks and raw html. > > Well, I think that escapes can happen (almost) anywhere, not just in > inline patterns. (Unless inline patterns handle everything except code > blocks...) Reading the documentation again, I'm not entirely sure why I > believe that. Perhaps confirmation from Mr. Gruber is in order. And searching the web, I see http://www.koders.com/noncode/fidB157BEC7D3FDEBB090E6CB9A1C01C4C4DD5DD434.aspx which says: 1.0.1 (14 Dec 2004): + Changed the syntax rules for code blocks and spans. Previously, backslash escapes for special Markdown characters were processed everywhere other than within inline HTML tags. Now, the contents of code blocks and spans are no longer processed for backslash escapes. This means that code blocks and spans are now treated literally, with no special rules to worry about regarding backslashes. **NOTE**: This changes the syntax from all previous versions of Markdown. Code blocks and spans involving backslash characters will now generate different output than before. So I guess escapes are only triggered within, uh, anything which isn't a code block or code span or inline html. Hmm, that's going to be ugly. Perhaps I'll just escape them all, and then in those three cases, handle the unescapes. Bleah. Is there a parent class for stuff which isn't a code block, code span, or inline html, by any chance? :) Thanks, Blake. |
|
From: Waylan L. <wa...@gm...> - 2008-02-17 23:53:56
|
On Feb 16, 2008 11:05 PM, Blake Winton <bw...@la...> wrote: > Waylan Limberg wrote: > > Blake, this is an interesting approach I hadn't thought of and I like it . > > Thanks! > > > When we run through the unescape code, > > how do we know that it was an escaped character, not something > > intentionally typed by the author that should be left alone? > > Or is that why you also escape the `&`? > > Yup, that's exactly why I escape the &. > > > Either way, I was never particularly fond of the way markdown > > currently handles escaping. I think your solution is much more elegant > > and I'd prefer to use something very much like it. > > > > However, I'm thinking that one of two things needs to happen: > > > > 1. The escaping needs to happen at the inline pattern level (or at > > least right before/after them, perhaps in _handleInline), rather than > > on the entire document. That eliminates the need to worry about > > messing with code blocks and raw html. > > Well, I think that escapes can happen (almost) anywhere, not just in > inline patterns. (Unless inline patterns handle everything except code > blocks...) Reading the documentation again, I'm not entirely sure why I > believe that. Perhaps confirmation from Mr. Gruber is in order. Something to keep in mind here. Python-markdown is not coded against markdown.pl, but rather Mr. Gruber's syntax rules. The internal implementation can be whatever we want it to be as long as the end result gets us the expected output. Mr. Gruber himself has said that there are some situations where markdown.pl is actually wrong and should not be looked to as an example. Anyway, yes in Python-Markdown inlinePatterns never see code blocks. > > Either way, though, I think that the other factor that kind of renders > this moot is that any characters that get escaped will get unescaped on > the way out, so it's as if we didn't do anything to them at all. We're > just hiding them from the internal processors. And the internal > processors can even pay attention to them if they want, since our > mapping is consistent. (If you see "&#x[0-9a-zA-Z]+;", you know it's an > escaped character. If you see "&", you know it was an &.) Yeah, thats clear to me now. if the author typed "&" it'd escape to "&#x26" and so on. I don't see any reason why we can't go with option 2 then. > > > 2. Assuming the above concern is moot, the escaping and unescaping > > should be pre and post processors respectively. Check the doc strings > > on the latest in svn (see below) for TextPreprocessor (line 413) and > > TextPostprocessor (line 945) which run on the entire document as a > > single string rather than split lines. > > Yeah, I could see that. Were the pre and post processors in 1.6 and I > just missed them? That depends on whether you have 1.6, 1.6a or 1.6b. Things kind of got messed up with that release. Some code in that release never made it into svn and some code in svn never made it into that release. 1.6b is the only one I recommend people use. Unfortunately, I'm not sure it's the one available with easy_install. Regardless, the TextPostprocessor is brand new. In fact, the code that removes and restores raw html are now text pre/post processors, so we can easily avoid escaping on raw html if we use them. > As a side note, I'm running against 1.6, because that > was what got installed when I typed "easy_install markdown". :) Either tonight to tomorrow I should be releasing 1.7 (currently at a release candidate - so I don't expect your patch to make it in -- sorry) > > > I appreciate all your hard work on this. However, it would be helpful > > if your diffs were against the latest in svn. There's been quite a few > > changes since 1.6. > > Fair enough. I'll see when I next have some free time, and give that a try. > > > You can checkout from here: > > svn co https://python-markdown.svn.sourceforge.net/svnroot/python-markdown > > python-markdown > > Which includes the test suite so you can check whether your breaking > > anything else. > > Ah, I was wondering where that was... Okay, I've got a copy in my > python 2.5 installation, and all the tests pass, so I should be good to > go with my modifications, I believe. > > Thanks, > Blake. > > -- ---- Waylan Limberg wa...@gm... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X