python-markdown-discuss

[Python-markdown-discuss] A couple more tests for some edge cases

[John S. <jo...@sz...>]

I was trying to ensure that a couple of code paths were actually being
reached.  While in the process of doing that, I created a couple of
tests that seem like they should work, but currently fail.

para-with-hr-test.patch adds a really simple test case:
   text, text, text
   ***
   more text

The output that's produced is completely missing the first line.

header-test.patch is one that I came up with while trying to make
__processParagraph() hit the other conditional (one where it
specifically looks for the start of a header).  Interestingly enough,
I was never able to get something to run down that path.  However, I
did find that if I embed a header into a list like so:
  1. My list

     ## blah, blah

Then I don't get a header element in the list.

-John

Re: [Python-markdown-discuss] A couple more tests for some edge cases

[John S. <jo...@sz...>]

On Thu, Nov 6, 2008 at 5:28 AM, John Szakmeister <jo...@sz...> wrote:
> I was trying to ensure that a couple of code paths were actually being
> reached.  While in the process of doing that, I created a couple of
> tests that seem like they should work, but currently fail.
>
> para-with-hr-test.patch adds a really simple test case:
>   text, text, text
>   ***
>   more text
>
> The output that's produced is completely missing the first line.
>
> header-test.patch is one that I came up with while trying to make
> __processParagraph() hit the other conditional (one where it
> specifically looks for the start of a header).  Interestingly enough,
> I was never able to get something to run down that path.  However, I
> did find that if I embed a header into a list like so:
>  1. My list
>
>     ## blah, blah
>
> Then I don't get a header element in the list.

Whups!  There was more in the header-test patch than should have been.
 Try the attached instead.

-John

Re: [Python-markdown-discuss] A couple more tests for some edge cases

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

Hi, John,

Since those tests fail at the moment, I won't integrate them yet, but
will treat them as bug reports.  I created a ticket for each of those
issues.  (http://www.freewisdom.org/projects/python-markdown/Tickets).
 The test suite is meant to be used for regression testing, so I would
rather not add failing test to it.

  - yuri

On Thu, Nov 6, 2008 at 2:28 AM, John Szakmeister <jo...@sz...> wrote:
> I was trying to ensure that a couple of code paths were actually being
> reached.  While in the process of doing that, I created a couple of
> tests that seem like they should work, but currently fail.

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

Re: [Python-markdown-discuss] A couple more tests for some edge cases

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

On Thu, Nov 6, 2008 at 5:28 AM, John Szakmeister <jo...@sz...> wrote:
> did find that if I embed a header into a list like so:
>  1. My list
>
>     ## blah, blah
>

Ah, yes, this one. You only have three spaces of indent.
Python-Markdown requires four or its not a child of the list item. If
you check Babelmark [1], about half the implementations require four
spaces and the other half just require indentation of any kind. This
has been a hotly debated topic on the markdown dicussion list in the
past which I'd rather not see repeated here.

Regardless of which side of that argument you may fall on, I've taken
the position that the current code base creates a technical limitation
which forces us to require four spaces. So, I'm likely to set the
ticket Yuri created for this as "wontfix" unless someone else can come
up with a solution I'm not aware of. I realize that sounds a little
harsh, but I don't have a better answer at this time.

Of course, there is the question as to why the header isn't parsed as
a header, just *not* as a child of the list item. Well, all
implementations require the hash to be the *very first* character on
the line or it's not a header. Again, see Babelmark [2]. Obviously,
that distinction becomes blurry when only whitespace defines children
of list items. It's easy to see how there can be multiple views on the
correct behavior here.

[1]: http://babelmark.bobtfish.net/?markdown=1.+My+list%0D%0A%0D%0A+++%23%23+blah,+blah
[2]: http://babelmark.bobtfish.net/?markdown=+%23%23+blah,+blah
-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] A couple more tests for some edge cases

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

> Of course, there is the question as to why the header isn't parsed as
> a header, just *not* as a child of the list item.

Yes, this is the one that confused me originally.  But it all makes
sense now.  I agree, wontfix.  Please append your explanation to the
bug when changing the status.

- yuri

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

Re: [Python-markdown-discuss] A couple more tests for some edge cases

[John S. <jo...@sz...>]

On Mon, Nov 10, 2008 at 10:12 AM, Waylan Limberg <wa...@gm...> wrote:
> On Thu, Nov 6, 2008 at 5:28 AM, John Szakmeister <jo...@sz...> wrote:
>> did find that if I embed a header into a list like so:
>>  1. My list
>>
>>     ## blah, blah
>>
>
> Ah, yes, this one. You only have three spaces of indent.
> Python-Markdown requires four or its not a child of the list item. If
> you check Babelmark [1], about half the implementations require four
> spaces and the other half just require indentation of any kind. This
> has been a hotly debated topic on the markdown dicussion list in the
> past which I'd rather not see repeated here.

Heh.  I didn't realize that... but you're right, it's there in the syntax guide.

> Regardless of which side of that argument you may fall on, I've taken
> the position that the current code base creates a technical limitation
> which forces us to require four spaces. So, I'm likely to set the
> ticket Yuri created for this as "wontfix" unless someone else can come
> up with a solution I'm not aware of. I realize that sounds a little
> harsh, but I don't have a better answer at this time.

No offense taken.

> Of course, there is the question as to why the header isn't parsed as
> a header, just *not* as a child of the list item. Well, all
> implementations require the hash to be the *very first* character on
> the line or it's not a header. Again, see Babelmark [2]. Obviously,
> that distinction becomes blurry when only whitespace defines children
> of list items. It's easy to see how there can be multiple views on the
> correct behavior here.

I understand.  Thanks for clearing that up.  It's also weird that the
space before the hash gets inserted into the HTML, rather than
stripped.  I'm not sure why that was happening.

-John

Re: [Python-markdown-discuss] A couple more tests for some edge cases

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

On Mon, Nov 10, 2008 at 10:34 AM, John Szakmeister <jo...@sz...> wrote:
[snip]
>
> I understand.  Thanks for clearing that up.  It's also weird that the
> space before the hash gets inserted into the HTML, rather than
> stripped.  I'm not sure why that was happening.
>

Well, I didn't write that code, but I suppose it's because whitespace
at the beginning of a line can be significant, so the parser is
careful to not strip any whitespace. Of course, once we get to the
paragraph processing code, that is no longer an issue, so we could
strip is there. However, then we only want to lstrip, so that we don't
strip manual line breaks (two spaces at end of line). Seeing
whitespace is insignificant in html, I'm guessing the thinking was
it's easier to leave whitespace alone. But, yeah, I probably would
have cleaned up that whitespace myself.



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