Markdown should process lists in paragraphs (and needs tests)

[bexelbie]

Markdown is the standardless standard :), however I thin k we should by default (or with an option) allow this to be valid and parsed without wrapping:

List Header
* item 1
* item 2
* item 3

This should generate a no-wrap entry in the pot, I think. Ideally, it should probably generate separate entries for each line, like a proper bulleted list.

[mquinson]

Which formater are you using here? I may well be blind, but it seems to be no Markdown format importer, is it? The first step for a proper MarkDown support is probably to have a dedicated formater, don't you think? As always, PR are warmely welcomed :-P

[intrigeri]

Which formater are you using here? I may well be blind, but it seems to be no Markdown format importer, is it? The first step for a proper MarkDown support is probably to have a dedicated formater, don't you think?

I have (vague) plans for other improvements in Markdown bullet list handling and noticed this discussion. @mquinson, I'm not sure I understand your comment correctly and wether I should be discouraged to improve the existing Markdown support (in Locale::Po4a::Text) because I would be required to first create a brand new class and think hard about design to avoid too much code duplication.

I would argue that it's best to improve Markdown syntax support in Locale::Po4a::Text as long as these conditions are met:

• the parse_markdown method remains small (currently it is pretty small; compare for example to the asciidoc support that takes about 50% of the SLOC in that class)
• improving support of Markdown syntax incidentally improves parsing of other simple text documents supported by that class; I think this should be easy given staying close to how most people would write text without knowing about Markdown is one design goal of that format; IMO it's already confirmed by the fact we already have pretty good Markdown support with very little Markdown-specific code.

Whenever any of these conditions is not met then I'll be all for creating a dedicated Locale::Po4a::Markdown class but right now I don't really see the point given it would basically be a copy of Locale::Po4a::Text minus the asciidoc, debian/control and fortunes bits.

What do you think?

[emmapeel2]

will a Locale::Po4a::Markdown class:

• strip the markdown from [[!meta title="this is our title"] and generate a mstr= "this is our title"?
• similar with [[!wikipedia Word desc="mydescription"] becoming mstr= "Word" and mstr= "mydescription" in .pot ?
• could maybe verify the existence of internal links?

[intrigeri]

will a Locale::Po4a::Markdown class:

• strip the markdown from [[!meta title="this is our title"] and generate a mstr= "this is our title"?
• similar with [[!wikipedia Word desc="mydescription"] becoming Word and mydescription in .pot ?

FYI this is all ikiwiki-specific and has thus nothing to do with Markdown.

[emmapeel2]

ok!

[bexelbie]

I'd be interested to know if this is a case where leveraging another CPAN based markdown processor would be of help. Otherwise, I agree that your criteria for splitting or not splitting look good.

[mquinson]

Hello, sorry for the delay.

I totally agree with @intrigeri that support for markdown can grow further in the text parser since it does not harm the text parser in any way for now. When we will have to choose to split the text here or there, depending on whether we assume that it's asciidoc or markdown, then we'll need to consider spliting the parsers. But not for now. So, my first question is now answered.

As for the remark of @bexelbie , I really fail to understand how you could use a regular parser to build a po4a transtractor. I'd be interested in an example ;)

[intrigeri]

I totally agree with @intrigeri that support for markdown can grow further in the text parser since it does not harm […]

Thanks!

[toddy15]

We now have a test case for this, see MarkDown.md in the test directory. From what I can tell, this issue seems to be solved -- the parser generates separate msgids for each bullet point and marks them as being wrappable.

I'm therefore closing this issue, please reopen it if you're missing some functionallity.