python-markdown-discuss

[Python-markdown-discuss] mdx_tables bug

[glin <gl...@se...>]

Hi,

on your wiki you have extension mdx_tables 
(http://www.freewisdom.org/projects/python-markdown/mdx_tables).

When I use some inline mark (like *something*, link etc.) in table cell, 
the cell content renders in reverse order. And I can use only one inline 
mark (others are not taken in account).

IMHO this extension shouldn't use _handleInline method, but 
_handleInlineWrapper2. I went through the source code of markdown and it 
appears, that _handleInline is only some 'private' function used by 
_handleInlineWrapper2 - so _handleInline applies only one pattern and 
returns chunks in reverse order, which is completely wrong and will do 
mess when you use any inline pattern in table.

So I think, that you should replace:

			for n in self.md._handleInline(t):
				if(type(n) == unicode):
					td.appendChild(doc.createTextNode(n))
				else:
					td.appendChild(n)

with:

			for item in self.md._handleInlineWrapper2(t) :
				td.appendChild(item)

I don't have permission to wiki so I cannot write it there, so I'm 
sending this email to mailinglist.

Glin

Re: [Python-markdown-discuss] mdx_tables bug

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

>  IMHO this extension shouldn't use _handleInline method, but
>  _handleInlineWrapper2. I went through the source code of markdown and it
>  appears, that _handleInline is only some 'private' function used by
>  _handleInlineWrapper2 - so _handleInline applies only one pattern and
>  returns chunks in reverse order, which is completely wrong and will do
>  mess when you use any inline pattern in table.

Thanks for pointing this out.  Strictly speaking, the extensions
shouldn't be using an of the _... methods.  So, we should probably
think whether this is a sign that we need to expose a bit more of the
API.  Anyway, I'll try to look into this.

>  I don't have permission to wiki so I cannot write it there, so I'm
>  sending this email to mailinglist.

We switched to git last week and I just checked in additional
extensions that I have, including this one.

The project is at http://gitorious.org/projects/python-markdown/ and
the "mainline" repository is at
http://gitorious.org/projects/python-markdown/repos/mainline/

Note that with git you don't need commit privileges to play - you can
just "clone" a repository (essentially make a branch), and commit into
it.  We can then merge from it later.

  - yuri

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

Re: [Python-markdown-discuss] mdx_tables bug

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

Bah, I failed to copy the list with my response. Here it is:

On Fri, May 2, 2008 at 11:33 AM, Waylan Limberg <wa...@gm...> wrote:
> Glin, thanks for your report. Personally, I have never used that
>  extension and don't even know if it works.
>
>  In any event, regarding your comments about _handleInline and
>  _handleInlineWrapper; those methods have been in flux. It used to be
>  that there was only _handleInline. Then _handleInlineWrapper was added
>  to wrap the first method. Later, the wrapper stopped calling
>  _handleInline altogether and did everything on it's own. As
>  _handleInline was still in the code, but (mostly) unused, this caused
>  all sorts of confusion.
>
>  Therefore in the latest release (1.7) the unused code was removed and
>  there is only one method _handleInline. I'd suggest upgrading to the
>  latest release of markdown and then see how it works.
>
>

On Fri, May 2, 2008 at 1:44 PM, Yuri Takhteyev <qar...@gm...> wrote:
> >  IMHO this extension shouldn't use _handleInline method, but
>  >  _handleInlineWrapper2. I went through the source code of markdown and it
>  >  appears, that _handleInline is only some 'private' function used by
>  >  _handleInlineWrapper2 - so _handleInline applies only one pattern and
>  >  returns chunks in reverse order, which is completely wrong and will do
>  >  mess when you use any inline pattern in table.
>
>  Thanks for pointing this out.  Strictly speaking, the extensions
>  shouldn't be using an of the _... methods.  So, we should probably
>  think whether this is a sign that we need to expose a bit more of the
>  API.  Anyway, I'll try to look into this.

As I was typing my response, this occurred to me as well. Perhaps at
the least we should provide a public method that wraps the private
method. Something like, handleInline(*args  **kwargs). That way, it is
both backward and forward compatible. However, I believe the gSOC
project will be addressing the inline patterns directly, so perhaps we
should wait and see what comes out of that before setting a new API.

>
>
>  >  I don't have permission to wiki so I cannot write it there, so I'm
>  >  sending this email to mailinglist.
>
>  We switched to git last week and I just checked in additional
>  extensions that I have, including this one.
>
>  The project is at http://gitorious.org/projects/python-markdown/ and
>  the "mainline" repository is at
>  http://gitorious.org/projects/python-markdown/repos/mainline/
>
Cool! Any reason why you didn't commit the latest versions of my
extensions (wikilink & codehilite)? I'll update them if you didn't
have any specific reason.

Anyway while were at it, mind if I add some more (I have 7 total) to
the mainline or would you prefer elsewhere for now?



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

Re: [Python-markdown-discuss] mdx_tables bug

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

>  As I was typing my response, this occurred to me as well. Perhaps at
>  the least we should provide a public method that wraps the private
>  method. Something like, handleInline(*args  **kwargs). That way, it is
>  both backward and forward compatible. However, I believe the gSOC
>  project will be addressing the inline patterns directly, so perhaps we
>  should wait and see what comes out of that before setting a new API.

This makes sense.  Let's put this on the list of things to do when we
do refactoring.  I think we need a public method there, but I am not
sure of top of my head which method should be made public.

>  Cool! Any reason why you didn't commit the latest versions of my
>  extensions (wikilink & codehilite)? I'll update them if you didn't
>  have any specific reason.

I just checked in what I had at the moment.  Feel free to add/update.

>  Anyway while were at it, mind if I add some more (I have 7 total) to
>  the mainline or would you prefer elsewhere for now?

I would like to avoid creating an expectation that all extensions must
be in the same place.  If people want to write extensions and maintain
those extensions themselves in their own code repository, that's quite
fine by me.  Furthermore, I really cannot commit to maintaining
extensions that I didn't write.

So, I think our gitorious repository is the best place for extensions
that either one of us is maintaining or extensions that look
abandoned.  For extensions that have a maintainer, I would prefer to
leave it up to the maintainer where they want to host it.  Which means
we'll have to do it on a case by case basis.

  - yuri

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