ordered/unordered list problem

[yegle]

sample code:

1. ordered
2. list

* unordered
* list

Tried python-markdown and http://daringfireball.net/projects/markdown/dingus, the actual output is a long ordered list with extra

tags

But on stackoverflow's online markdown editor ( http://stackoverflow.com/questions/ask ), the output is OK ( a ordered list and an unordered list )

[waylan]

As difficult as it may seem, stackoverflow has it wrong. Python-Markdown's goal is to emulate markdown.pl (the original) as closely as possible. So while markdown.pl's behavior in this case is hard to wrap your head around, we will continue to support that behavior. Stackoverflow on the other hand, is more interested in generating output that does not surprise its users - people who may not be familiar with the intricacies of markdown syntax.

Of course, our Extension API makes it relativity easy for someone to alter the default behavior however they would like.

No bug hear so I'm closing this.

[ghost]

Sorry, Waylan, but it is not acceptable to say "this is a convoluted, ridiculously hard-to-understand 'feature' of markdown". If the result is totally non-intuitive to the user it is totally non-Markdown. Period. If I type

1. ordered
2. list

* unordered
* list

and I get

1.  ordered
2.  list

3.  unordered
4.  list

that is not acceptable on any level.

[waylan]

On Sat, Jan 7, 2012 at 10:54 PM, NevarMaor wrote:

Sorry, Waylan, but it is not acceptable to say "this is a convoluted, ridiculously hard-to-understand 'feature' of markdown". If the result is totally non-intuitive to the user it is totally non-Markdown.
that is not acceptable on any level.

I understand your frustration. However, I didn't write the syntax
rules. I (and others) just implemented a parser that follows them.

As I see it, the Python-Markdown project has two primary goals:

1. Implement a parser that follows as closely as possible the rules
   and behavior of the baseline parser (markdown.pl), both written by
   John Gruber.
2. Provide an API that would allow any third party user (you?) to
   override/add/change the behavior of the parser as they see fit for
   there own use.

Give the number of people who dislike the behavior in question, I
expected that someone would have written an extension which alters it
by now. In fact, I'm inclined to include such an extension in the
library as an option for everyone, provided one is offered for
inclusion.

Why haven't I written such an extension myself? For one, I maintain
this project in my limited spare time. Second, I've never had a
problem with the current behavior in my own documents (which may just
be because I wrote the current code and made a conscience decision to
specifically code the current behavior - why would I write a document
that doesn't follow it). Of course, this being open source software,
anyone is welcome to scratch this itch if they want - it just needs to
be an optional behavior, not the default.

I didn't like the current behavior at first either. However, search
the archives on the markdown discussion list and you will see many
debates about this issue (which no one wants to have all over again -
thus the silence the last time this was brought up). The argument that
convinced me is that there are many thousands of users of markdown who
each have many hundreds or even thousands of documents that all depend
on the current behavior. Document authors have been authoring
documents for years copying and pasting list items from one list to
another and have lists of mixed types. As it has been explained to me,
they never bothered to "fix" the list type on any items except the
first in each list because they knew it didn't matter. If the parser
behavior is changed, all those documents are broken. That is
"unacceptable". Therefore the current behavior stands as the default.

---

\X/ /-\ `/ |_ /-\ ||
Waylan Limberg

[davidchambers]

The argument that convinced me is that there are many thousands of users of markdown who each have many hundreds or even thousands of documents that all depend on the current behavior.

I sympathize with both parties but felt compelled to draw attention to the straw man above. Yes, there are thousands upon thousands of Markdown documents in existence. Yes, each of these documents was written at a time when Markdown.pl included this bug. But it's a stretch to suggest that a significant number of these documents rely on this nonsensical behaviour.

Closing the issue because “that's what Markdown.pl does” is fine, but backwards compatibility isn't a concern here in practice.

[ghost]

I can't see anyone typing lists to consciously take advantage of this "feature". It is entirely counterintuitive and, as I stated earlier, opposed to Markdown's stated philosophy of producing what you expect. However, Markdown is apparently locked beyond repair to an abandoned, frankly half-finished, specification - kind of like latin. Unfortunate, because overall I do find it the most comfortable lightweight markup to work with.

[skurfer]

I agree with @davidchambers. The business about existing documents tells us that there are a lot of users that have been tolerating this behavior. It doesn’t say anything about the number of users depending on it. For that, we can only guess. My guess is 0. ;-)

[waylan]

So a lot of people want this feature and as I said previously, I'm not opposed to an extension. I just started throwing an extension together and in 15-20 minutes have a working extension - well almost.

The original example provided above by yegle works. But what about this example (no blank line):

1. ordered
2. list
* unordered
* list

Also, any ideas for a good name for the extension? I'm currently using "sane_lists" but am open to suggestions.

Oh, and making this new behavior the default is not an option. Any such requests will be ignored.

[skurfer]

I just started throwing an extension together

The effort is appreciated.

For the example with no blank line, I would treat it much the same way this would be treated

paragraph
* unordered
* list

That is, completely fall apart and force the author to think about what they did wrong. :-)

As for the name, I can’t think of anything better. Here are some that are worse: adjacent_lists, list_mixing

[waylan]

For some reason github isn't linking to my commit from this issue. The extension was added in commit a9cd895.