python-markdown-discuss — A general purpose discussion list

Re: [Python-markdown-discuss] Python 3.0

[Yuri T. <qar...@gm...>]

> Nice :) What about adding version check ? Something like this:
>
>     if sys.version >= "3.0":
>         from html import entities as htmlentitydefs
>     else:
>         import htmlentitydefs

We shouldn't _have_ to do that, but works for now. I also realized
that "para-with-hr" already fails, so the new problem is just limited
to test-markdown.py. (Test-markdown.py fails in python 3.0 when it
tries to save diff for a failed test.)

So, with the most recent commit (cd73ef7), all you have to do is run
2to3 on "markdown", "markdown.py" and (optionally) "test-markdown.py".

- yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] Python 3.0

[Artem Y. <se...@sp...>]

On Thu, Dec 4, 2008 at 11:42 PM, Yuri Takhteyev <qar...@gm...> wrote:

>
> After that you need to make one change manually, in
> markdown/inlinepatterns.py:
>
> -import htmlentitydefs
> +from html import entities as htmlentitydefs
>
> After that, the script seems to work for all test cases except
> "para-with-hr". The test-markdown.py itself is broken in 3.0, though,
> when it comes to saving the results to a file. As a quick fix, you can
> disable this:
>
> test-markdown.py:
> -    htmlDiffFile.write(diffsBuffer.decode("utf8"))
> +    #htmlDiffFile.write(diffsBuffer.decode("utf8"))
>
>
Nice :) What about adding version check ? Something like this:

    if sys.version >= "3.0":
        from html import entities as htmlentitydefs
    else:
        import htmlentitydefs

[Python-markdown-discuss] Python 3.0

[Yuri T. <qar...@gm...>]

I tried running python markdown the recently released py3k and after
two commits it only requires 2to3 and one manual fix. The recommended
method for maintaining a library that should work as both 2.x and 3.x
is to maintain it in 2.x and rely on automatic conversion with 2to3
with no further manual changes. So, we should think of how to fix up
our code so that it works with 2.x and then converts into
3.0-compliant code when we run 2to3.

Get the newest version from git, then run 2to3:

2to3 -w markdown
2to3 -w markdown.py
2to3 -w test-markdown.py

After that you need to make one change manually, in markdown/inlinepatterns.py:

-import htmlentitydefs
+from html import entities as htmlentitydefs

After that, the script seems to work for all test cases except
"para-with-hr". The test-markdown.py itself is broken in 3.0, though,
when it comes to saving the results to a file. As a quick fix, you can
disable this:

test-markdown.py:
-    htmlDiffFile.write(diffsBuffer.decode("utf8"))
+    #htmlDiffFile.write(diffsBuffer.decode("utf8"))

Some of the extensions fail too, though those problems might actually
be in test-markdown.py

Let's not worry about the extensions working with 3.0 for our 2.0
release, though. I'll try to fix up the test script, though it perhaps
would be ok to have a different version of it for 3.0.

I am not planning on committing the output of 2to3 to avoid confusion.
At least for now, anyone who wants to use markdown with python 3.0
should get the latest version from git and run 2to3 on it themselves.

 - yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] disutils package proposal for Simple Tables extension (mdx_tables.py)

[Waylan L. <wa...@gm...>]

On Tue, Dec 2, 2008 at 12:43 PM, Marco Pantaleoni
<mar...@gm...> wrote:
> Ok, glad to hear that it will be included. Btw, is there any
> time-frame for the next release?
>

When its ready, which hopefully will be very soon. I realize that's
rather vague, but we are volunteering our personal time to the project
so we do what we can when we find the time.

On the plus side, my todo list is shorter than ever. If you'd like to
help, feel free to test, find bugs, and submit patches. That's the
best way to keep things moving.

-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] disutils package proposal for Simple Tables extension (mdx_tables.py)

[Marco P. <mar...@gm...>]

Ok, glad to hear that it will be included. Btw, is there any
time-frame for the next release?

Thanks.
Bye,
Marco

On Tue, Dec 2, 2008 at 6:33 PM, Waylan Limberg <wa...@gm...> wrote:
> Thanks Marco, however I don't think it's necessary. That extension
> (along with many others) will be included in the next release of
> Python-Markdown. I don't see the need to have it packaged separately
> as well.
>
>
> On Tue, Dec 2, 2008 at 12:10 PM, Marco Pantaleoni
> <mar...@gm...> wrote:
>> Hello,
>> since I've not found it in the usual places, I've put together a distutils
>> package for the Simple Tables markdown extension (mdx_tables.py).
>> The source package is attached.
>> I'll wait for your approval before registering it with PyPI (or sending it
>> to /dev/null :-)
>>
>> Cheers,
>> Marco
>>
>> --
>> Marco Pantaleoni
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>>
>
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>



-- 
Marco Pantaleoni

Re: [Python-markdown-discuss] disutils package proposal for Simple Tables extension (mdx_tables.py)

[Waylan L. <wa...@gm...>]

Thanks Marco, however I don't think it's necessary. That extension
(along with many others) will be included in the next release of
Python-Markdown. I don't see the need to have it packaged separately
as well.


On Tue, Dec 2, 2008 at 12:10 PM, Marco Pantaleoni
<mar...@gm...> wrote:
> Hello,
> since I've not found it in the usual places, I've put together a distutils
> package for the Simple Tables markdown extension (mdx_tables.py).
> The source package is attached.
> I'll wait for your approval before registering it with PyPI (or sending it
> to /dev/null :-)
>
> Cheers,
> Marco
>
> --
> Marco Pantaleoni
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>
>



-- 
----
Waylan Limberg
wa...@gm...

[Python-markdown-discuss] [plain text] disutils package proposal for Simple Tables extension (mdx_tables.py)

[Marco P. <mar...@gm...>]

Apologies for the HTML message. Here it is again...

Hello,
since I've not found it in the usual places, I've put together a
distutils package for the Simple Tables markdown extension
(mdx_tables.py).
The source package is attached.
I'll wait for your approval before registering it with PyPI (or
sending it to /dev/null :-)

Cheers,
Marco

--
Marco Pantaleoni

Re: [Python-markdown-discuss] Fwd: Lists and code blocks

[Waylan L. <wa...@gm...>]

Lee, yeah, I got it before. I just haven't had time to do anything
with it. It's been a little busy. However, I'm snowed in tonight, so I
have a few free hours unexpectedly. I intend to go through each
extension and make sure they are working after I take care of some
unrelated, more-pressing (to me) matters. Look for it later tonight.

On Thu, Nov 20, 2008 at 5:56 PM, Lee Cantey <lc...@gm...> wrote:
> I've re-posting this since the TOC extension is broken due to the
> recent refactorings in the tree.
>
> ---------- Forwarded message ----------
> On Tue, Nov 18, 2008 at 10:29 AM, Waylan Limberg <wa...@gm...> wrote:
>> I pushed the fix for this a little while ago and added a test. We
>> shouldn't be doing that again. Thanks for the report.
>
> The fix is working fine here, thanks.  I'm also using the toc
> extension which isn't working after the recent refactorings due to the
> layout changes.  I 'm attaching the patch I'm using here.
>
> Thanks,
> Lee
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>
>



-- 
----
Waylan Limberg
wa...@gm...

[Python-markdown-discuss] Fwd: Lists and code blocks

[Lee C. <lc...@gm...>]

I've re-posting this since the TOC extension is broken due to the
recent refactorings in the tree.

---------- Forwarded message ----------
On Tue, Nov 18, 2008 at 10:29 AM, Waylan Limberg <wa...@gm...> wrote:
> I pushed the fix for this a little while ago and added a test. We
> shouldn't be doing that again. Thanks for the report.

The fix is working fine here, thanks.  I'm also using the toc
extension which isn't working after the recent refactorings due to the
layout changes.  I 'm attaching the patch I'm using here.

Thanks,
Lee

Re: [Python-markdown-discuss] Lists and code blocks

[Lee C. <lc...@gm...>]

Hello Waylan,

On Tue, Nov 18, 2008 at 10:29 AM, Waylan Limberg <wa...@gm...> wrote:
> I pushed the fix for this a little while ago and added a test. We
> shouldn't be doing that again. Thanks for the report.

The fix is working fine here, thanks.  I'm also using the toc
extension which isn't working after the recent refactorings due to the
layout changes.  I 'm attaching the patch I'm using here.

Thanks,
Lee

Re: [Python-markdown-discuss] Lists and code blocks

[Lee C. <lc...@gm...>]

Thanks Waylan, I'll give it a go when it shows up.

Regards,
Lee

Re: [Python-markdown-discuss] Lists and code blocks

[Waylan L. <wa...@gm...>]

Hmm, apparently I only committed it locally, but didn't push yet. And
my ssh connection to my dev box has decided to stop working. Guess
I'll have to push when I get home later today. Sorry for the noise.

On Tue, Nov 18, 2008 at 1:29 PM, Waylan Limberg <wa...@gm...> wrote:
> I pushed the fix for this a little while ago and added a test. We
> shouldn't be doing that again. Thanks for the report.
>
> On Mon, Nov 17, 2008 at 11:05 PM, Waylan Limberg <wa...@gm...> wrote:
>> Thanks Lee. It appears that you just found a test case that is not
>> tested anywhere in the tests. Which might explain why I missed it. I'm
>> working on it.
>>
>> On Mon, Nov 17, 2008 at 9:03 PM, Lee Cantey <lc...@gm...> wrote:
>>> Hello,
>>>
>>> I've run across a regression starting at rev 8d367ca7 where using a
>>> code block within a list item isn't working.
>>>
>>> * list item with a code block:
>>>
>>>        This is *code*
>>>
>>> Regards,
>>> Lee
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Python-markdown-discuss mailing list
>>> Pyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>>
>>
>>
>>
>> --
>> ----
>> Waylan Limberg
>> wa...@gm...
>>
>
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Lists and code blocks

[Waylan L. <wa...@gm...>]

I pushed the fix for this a little while ago and added a test. We
shouldn't be doing that again. Thanks for the report.

On Mon, Nov 17, 2008 at 11:05 PM, Waylan Limberg <wa...@gm...> wrote:
> Thanks Lee. It appears that you just found a test case that is not
> tested anywhere in the tests. Which might explain why I missed it. I'm
> working on it.
>
> On Mon, Nov 17, 2008 at 9:03 PM, Lee Cantey <lc...@gm...> wrote:
>> Hello,
>>
>> I've run across a regression starting at rev 8d367ca7 where using a
>> code block within a list item isn't working.
>>
>> * list item with a code block:
>>
>>        This is *code*
>>
>> Regards,
>> Lee
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Lists and code blocks

[Waylan L. <wa...@gm...>]

Thanks Lee. It appears that you just found a test case that is not
tested anywhere in the tests. Which might explain why I missed it. I'm
working on it.

On Mon, Nov 17, 2008 at 9:03 PM, Lee Cantey <lc...@gm...> wrote:
> Hello,
>
> I've run across a regression starting at rev 8d367ca7 where using a
> code block within a list item isn't working.
>
> * list item with a code block:
>
>        This is *code*
>
> Regards,
> Lee
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
----
Waylan Limberg
wa...@gm...

[Python-markdown-discuss] Lists and code blocks

[Lee C. <lc...@gm...>]

Hello,

I've run across a regression starting at rev 8d367ca7 where using a
code block within a list item isn't working.

* list item with a code block:

        This is *code*

Regards,
Lee

Re: [Python-markdown-discuss] breaking up into multiple files

[Waylan L. <wa...@gm...>]

On Mon, Nov 17, 2008 at 3:27 AM, Yuri Takhteyev <qar...@gm...> wrote:
> Now that we have all the logic broken up, it's a shame to have it all
> in a single giant file.  Here is an attempt at refactoring:
>
> http://gitorious.org/projects/python-markdown/repos/mainline/logs/repackaging
>
> What do you think?

I've wanted to do this for some time. I like it! It also means we can
put the extensions at ``markdown.extensions.footnotes``, rather than
``markdown_extensions.footnotes``. Much better IMO.

>
> Note that the command line markdown.py still works as long as the
> "markdown" directory is either in the path.

Cool!

> I didn't break things up all the way yet.

It looks like `postprocessors`, `util`, and maybe `etree` are left to do.

I noticed you went with `linepreprocessors`. As there are only one
kind of preprocessors, why not just `preprocessors`?



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] processors as functions

[Waylan L. <wa...@gm...>]

On Mon, Nov 17, 2008 at 2:17 AM, Yuri Takhteyev <qar...@gm...> wrote:
>> Meh. I'v thought about this before and even wondered why you used
>> classes back when I started my first extension, but the class gives us
>> so much more. Look at the InlinePatterns. Many of them are subclasses
>> that override only part of the functionality. In fact, a few don't
>> even have a run method, they just override an auxiliary method.
>> Actually, there are quite a few auxiliary methods that would now
>> litter the markdown namespace unnecessarily. Using classes keeps
>> things neat, compartmentalized, and DRY.
>
> Ok, a variation on this idea: each odict would be allowed to take as
> entries any callable objects - either a function or an instance of a
> callable class would do.  We can stick with classes for our
> implementations, but let the users extend the functionality by adding
> either instances or functions.
>

That would be a simple change - just rename all 'run' methods to
'__call__' in the code and adjust the calling code accordingly. I have
some reservations[^1], but also see it as slightly more pythonic.
Whatever.

If we did do this, I would suggest adding a utility function to add a
regex pattern to a function:

    def makePattern(regex, callable):
        return callable.pattern = regex

That may not be exactly what we want, but you get the idea. Then, one could do:

       md.inlinePatterns.add("footnote",
                         makePattern(FOOTNOTE_RE,
handleFootnotePattern), "<reference")

Of course, this would not be necessary for the callable classes (as
they already do this internally), just functions. But, that way the
odict would only ever contain one object each (no tuples), and the
regex would still be mapped to the pattern/processor.

[^1]: My concern is that some newcomers to python may see the callable
classes as a higher barrier of entry as they aren't up on the
interworkings of python. That also means that our documentation may
have to spend at least a little time educating people about python
itself. That said, it is the python way, so it can't be all that bad.


-- 
----
Waylan Limberg
wa...@gm...

[Python-markdown-discuss] breaking up into multiple files

[Yuri T. <qar...@gm...>]

Now that we have all the logic broken up, it's a shame to have it all
in a single giant file.  Here is an attempt at refactoring:

http://gitorious.org/projects/python-markdown/repos/mainline/logs/repackaging

What do you think?

Note that the command line markdown.py still works as long as the
"markdown" directory is either in the path.  I didn't break things up
all the way yet.  We should be able to reduce the core file to about
500 lines or less.

  - yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] processors as functions

[Yuri T. <qar...@gm...>]

> Meh. I'v thought about this before and even wondered why you used
> classes back when I started my first extension, but the class gives us
> so much more. Look at the InlinePatterns. Many of them are subclasses
> that override only part of the functionality. In fact, a few don't
> even have a run method, they just override an auxiliary method.
> Actually, there are quite a few auxiliary methods that would now
> litter the markdown namespace unnecessarily. Using classes keeps
> things neat, compartmentalized, and DRY.

Ok, a variation on this idea: each odict would be allowed to take as
entries any callable objects - either a function or an instance of a
callable class would do.  We can stick with classes for our
implementations, but let the users extend the functionality by adding
either instances or functions.

- yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] New Core Parser

[Waylan L. <wa...@gm...>]

In case anyone is interested, I just pushed changes to
docs/writing_extensions.txt [1] for the new BlockParser (starting at
line 165). The code is documented as well, but sometimes the overview
text is easier to start with.

Any corrections, additions, criticisms or other feedback is welcome.

[1]: http://gitorious.org/projects/python-markdown/repos/mainline/blobs/master/docs%2Fwriting_extensions.txt#line165

On Thu, Nov 13, 2008 at 11:44 PM, Waylan Limberg <wa...@gm...> wrote:
> On Thu, Nov 13, 2008 at 8:58 AM, Waylan Limberg <wa...@gm...> wrote:
>> On Thu, Nov 13, 2008 at 4:26 AM, Yuri Takhteyev <qar...@gm...> wrote:
>>>
>>> Yes, this certainly looks more customizable and is also easier to
>>> understand.  Good job!  If we can switch to this implementation
>>> without breaking too many tests, then let's just do this.
>>
>> Thanks. I crunched on the bugs last night and only have one failing
>> test left. I'll push once I get a a few implementation details worked
>> out.
>>
>
> FYI, I just pushed this. The only failing test is for definition lists
> as I haven't touched that yet. Everything else is passing and we
> *should* be more similar to perl and php implementations. Enjoy!
>
> I just marked tickets 1 & 21 as fixed. We now have no open tickets
> except 8 which is a nice-to-have. Although, we already do it better
> than everyone else, so it doesn't really matter.
>
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] processors as functions

[Waylan L. <wa...@gm...>]

On Fri, Nov 14, 2008 at 9:44 AM, Waylan Limberg <wa...@gm...> wrote:
[snip]
> method to simulate a function. But even then, as callables can't be
> instances, I couldn't override ``__init__`` to pass in extra arguments
> and/or set state on init.
>

Sorry, I misspoke here. Actually ``__call__`` only works with an
instance of a class, so this would work as the instance needs to be
initialized first. But, I think that would be more confusing than the
current way of doing things to the beginner.



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] processors as functions

[Waylan L. <wa...@gm...>]

On Fri, Nov 14, 2008 at 4:44 AM, Yuri Takhteyev <qar...@gm...> wrote:
> Now that we are changing so much, I want to propose a change that has
> been on my mind for quite some time.  Back in the day I made a
> decision to implement all processors as classes.  Since then I've been
> thinking that perhaps implementing them simply as functions would make
> things a lot easier and intuitive.  It may make some complicated cases
> a little more complicated, but will simplify the simple cases, which

Meh. I'v thought about this before and even wondered why you used
classes back when I started my first extension, but the class gives us
so much more. Look at the InlinePatterns. Many of them are subclasses
that override only part of the functionality. In fact, a few don't
even have a run method, they just override an auxiliary method.
Actually, there are quite a few auxiliary methods that would now
litter the markdown namespace unnecessarily. Using classes keeps
things neat, compartmentalized, and DRY.

On a related note, when I first started to write the new BlockParser,
I was intending to use functions rather than classes for the
processors, but it quickly became clear that classes were a much
better solution. And then there are a few extensions in which I use
the class to remember state. That wouldn't work with a function. Yeah,
we can always keep state on the Markdown instance, but if the only
place we use that state is within one processor, why litter the
Markdown instance?

Personally, if you made this change, I would still be inclined to use
classes with the ``__call__`` method in place of the current ``run``
method to simulate a function. But even then, as callables can't be
instances, I couldn't override ``__init__`` to pass in extra arguments
and/or set state on init.

> would make it easier for people to write simple extensions.

I agree this is important, but I think the answer is good
documentation. Have you read my documentation [1] for writing
extensions (the core parser part needs updating)? Once it's all
spelled out, it doesn't seem that hard IMO.

[1]: http://gitorious.org/projects/python-markdown/repos/mainline/blobs/master/docs/writing_extensions.txt

-- 
----
Waylan Limberg
wa...@gm...

[Python-markdown-discuss] processors as functions

[Yuri T. <qar...@gm...>]

Now that we are changing so much, I want to propose a change that has
been on my mind for quite some time.  Back in the day I made a
decision to implement all processors as classes.  Since then I've been
thinking that perhaps implementing them simply as functions would make
things a lot easier and intuitive.  It may make some complicated cases
a little more complicated, but will simplify the simple cases, which
would make it easier for people to write simple extensions.

For instance, we would have

	def handleFootnotePattern(md, match) :
		sup = etree.Element("sup")
		a = etree.SubElement(sup, "a")
		id = m.group(2)
		sup.set('id', md.footnotes.makeFootnoteRefId(id))
		a.set('href', '#' + md.footnotes.makeFootnoteId(id))
		a.set('rel', 'footnote')
		a.text = str(md.footnotes.footnotes.index(id) + 1)
		return sup

instead of:

	class FootnotePattern(markdown.Pattern):
		""" InlinePattern for footnote markers in a document's body text. """

		def __init__(self, pattern, footnotes):
		    markdown.Pattern.__init__(self, pattern)
		    self.footnotes = footnotes

		def handleMatch(self, m):
		    sup = etree.Element("sup")
		    a = etree.SubElement(sup, "a")
		    id = m.group(2)
		    sup.set('id', self.footnotes.makeFootnoteRefId(id))
		    a.set('href', '#' + self.footnotes.makeFootnoteId(id))
		    a.set('rel', 'footnote')
		    a.text = str(self.footnotes.footnotes.index(id) + 1)
		    return sup

and then:

	md.inlinePatterns.add("footnote",
                          (FOOTNOTE_RE, handleFootnotePattern), "<reference")

instead of:

	md.inlinePatterns.add("footnote",
                          FootnotePattern(FOOTNOTE_RE, self), "<reference")

If we do this, I suggest that we do this for _all_ types of
processors.  I don't think this would be too complicated to implement.

 - yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] New Core Parser

[Waylan L. <wa...@gm...>]

On Thu, Nov 13, 2008 at 8:58 AM, Waylan Limberg <wa...@gm...> wrote:
> On Thu, Nov 13, 2008 at 4:26 AM, Yuri Takhteyev <qar...@gm...> wrote:
>>
>> Yes, this certainly looks more customizable and is also easier to
>> understand.  Good job!  If we can switch to this implementation
>> without breaking too many tests, then let's just do this.
>
> Thanks. I crunched on the bugs last night and only have one failing
> test left. I'll push once I get a a few implementation details worked
> out.
>

FYI, I just pushed this. The only failing test is for definition lists
as I haven't touched that yet. Everything else is passing and we
*should* be more similar to perl and php implementations. Enjoy!

I just marked tickets 1 & 21 as fixed. We now have no open tickets
except 8 which is a nice-to-have. Although, we already do it better
than everyone else, so it doesn't really matter.



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] New Core Parser

[Waylan L. <wa...@gm...>]

On Thu, Nov 13, 2008 at 4:26 AM, Yuri Takhteyev <qar...@gm...> wrote:
>> Well, I'm satisfied enough with what I have to release it into the
>> wild. I'm not convinced it's ready for prime time just yet, but I
>> think it's mostly there. I started this as an extension that replaced
>> the core parser rather than hacking on the existing code in
>> markdown.py. For one, it made timing against the old code easier, and
>> two, with none of the old code in front of me, it forced me to start
>> from scratch. Unfortunately, after working out the remaining edge
>> cases, it is barely any faster than the old code, but it is much more
>> customizable, so we do gain a lot IMO.
>
> Yes, this certainly looks more customizable and is also easier to
> understand.  Good job!  If we can switch to this implementation
> without breaking too many tests, then let's just do this.

Thanks. I crunched on the bugs last night and only have one failing
test left. I'll push once I get a a few implementation details worked
out.

Speaking of which, would you suggest leaving the processors in the
parser class, or should they be defined in the Markdown class and
passed into the parser on init? The latter seems to provide a more
consistent api for extension authors to me. Any input in that respect
would be appreciated.

>
> A few small details:
>
> 1. Now that this is fresh in your head, please add comments on how this works.
> 2. I would get rid of all abbreviations.  E.g., I would make it
> "SetexHeaderProcessor" instead of "SHeaderProcessor".
> 3. I would replace 4 with TAB_LENGTH everywhere.
>
All good points. Will do.

-- 
----
Waylan Limberg
wa...@gm...