Re: [Python-markdown-discuss] GSoC current progress

[Artem Y. <ne...@gm...>]

Waylan Limberg wrote:
> On Sat, Jul 19, 2008 at 9:28 AM, Artem Yunusov <ne...@gm...> wrote:
>   
>> I deleted Pattern.contentGroup attribute, that I previously added,
>> because I solved this problem using regexps. I also created new regexp
>> for links, it partly solves ticket#4 because it works fine, until you'll
>> try to insert nested parenthesis in link, in Perl  implementation it's
>> solved with recursive  regexp, but I don't see any way of doing it in
>> Python using regexps.
>>
>>     
>
> Yeah I was just looking at that yesterday. A small annoyance.
>
> [snip]
>   

Maybe we should use some combination of parsing and regexps here. But I 
think it's not very important bug now.

>   
>> Maybe some refactoring. For instance class CorePatterns scheduled for
>> refactoring, but now I don't have an idea what can be a better
>> replacement for it.
>>
>>     
>
> I'd leave this alone for now. IMO, what needs to happen is the current
> code should be (mostly) thrown out (sorry Yuri) and we need to create
> some easily extendable API where each block-level parser is its own
> class or something (perhaps a state machine or similar). And in the
> process, we need to lose the recursion that we have now. I suspect
> this would be a major undertaking and an entire summer project in
> itself.
>
> The recursion issue could probably be dealt with on it's own, but
> while we're in there, we might as well make is extendable. Currently,
> if you wanted to write an extension that added another block-level
> type (say definition lists) you would have to both create a processor
> for them and then override the _processSection method (through a
> monkey patch) with your own that reimplements the entire existing
> method with the appropriate calls to your new definition list
> processor added into the logic. It's ugly and complicated and doesn't
> work if multiple extensions take the same approach.
>   

Hmm, so then there will be new type of extensions, something called 
block level patterns.
I think it'll slow down markdown, but sure it'll be quite useful.
Yuri, what do you think about it?

> However, that does bring to mind something you could do. Perhaps try
> creating a definition list extension as a preproccessor. Not sure how
> you'd get it into the DOM, but I'm sure there are a few possibilities.
> Just be sure to follow the syntax used by PHP Markdown Extra. That
> seems to be the community accepted syntax.
>
> Oh, and while I'm at it, I should mention that I committed a small
> patch [1] for an undocumented bug that David had reintroduced while
> refactoring the extension api. Perhaps you're keeping an eye on the
> master repo and already know about it, but you may want to merge that
> into your code.
>
> [1]: http://gitorious.org/projects/python-markdown/repos/mainline/commits/bf7cf776daa26d734c10a6039efe64113f066045
>   

Yep, I saw it, I think I'll integrate it in GSoC version.