Re: A bug or an undocumented feature?

This is the exact "bug" I joined this mailing list to "report" (having also used Python-Markdown), and what fueled my desire to see Markdown 2.0. I do still very much wish we could agree that this really is a bug, as far as being a completely unexpected result. Very sad t

re: A bug or an undocumented feature?

spencer said: >"non-pure" Markdown parsers that actually >work how every person knows it should work not sure it's 100% "every person" unanimous, but even 75% (which is 3-1) should carry the day with a system that's specifically meant to be "intuitive". -bowerbird

Re: A bug or an undocumented feature?

of all the time saved not having to explain this over and over. :) Spencer On Wednesday, December 21, 2011 at 7:27 PM, yegle wrote: > Hi list, > > I'm using Python-Markdown and found a potential bug ( or an > undocumented feature? ) > Can anyone confirm this? Thank you :-)

A bug or an undocumented feature?

Hi list, I'm using Python-Markdown and found a potential bug ( or an undocumented feature? ) Can anyone confirm this? Thank you :-) Bug report on Python-Markdown issue list: https://github.com/waylan/Python-Markdown/issues/64 ___ Markdown-Di

Re: Bug using inline code blocks in nested lists?

On Fri, Mar 18, 2011 at 1:54 PM, John MacFarlane wrote: > PS. Is babelmark still actively maintained?  The versions of pandoc > and peg-markdown there are a couple of years old. > > John I was curious about this, too. I'll want to get MMD 3.0 in there as well. I've been using babelmark a lot

Re: Bug using inline code blocks in nested lists?

d of: > > > asdf > ` asdf `asdf` > > > Am I missing something or is this a bug? It's a bug. Try another implementation. You can see from http://babelmark.bobtfish.net/ that many other implementations parse this input correctly. PS. Is babelmark still actively mainta

Bug using inline code blocks in nested lists?

Hi, I am generating a nice document with some inline code blocks and came around the following error: 1. asdf - \` asdf `` `asdf` `` produces: asdf ` asdf asdf instead of: asdf ` asdf `asdf` Am I missing something or is this a bug? Regards, Chris smime.p7s Description: S/MIME

Re: Bug?

On Sat, Mar 29, 2008 at 4:52 PM, Mark Eli Kalderon <[EMAIL PROTECTED]> wrote: > Hi, > > This might be related to the bug reported earlier about parsing URLs > with parens, but the following looks like a bug to me: > > [ZIP archives](http://en.wikipedia.org/wiki/ZIP_(fi

Bug?

Hi, This might be related to the bug reported earlier about parsing URLs with parens, but the following looks like a bug to me: [ZIP archives](http://en.wikipedia.org/wiki/ZIP_(file_format) "ZIP (file format) - Wikipedia, the free encyclopedia") gets rendered by Markdown 1.01

Re: Possible bug in handling of HTML comments

On 18 Jan 2008, at 23:09, Fletcher T. Penney wrote: I was hoping for a more elegant solution (such as not encoding them in the first place), but for now I guess this will do. Yeah, it's truly hateful. I modified the encoding regex to not encode them in the first place, but it was hella sl

Re: Possible bug in handling of HTML comments

I was hoping for a more elegant solution (such as not encoding them in the first place), but for now I guess this will do. I will add this to the next version of MultiMarkdown as well. Thanks Tomas. Fletcher Penney On Jan 14, 2008, at 1:05 PM, Tomas Doran wrote: On 14 Jan 2008, at 02:

Re: Possible bug in handling of HTML comments

On 14 Jan 2008, at 02:08, Fletcher T. Penney wrote: It appears that the _EncodeAmpsAndAngles routine is being run over the comments, converting & and < to the HTML markup. I tried adding & and < to $g_escape_table, and then protecting them. This seemed to work, but caused other problems

Re: Possible bug in handling of HTML comments

Le 2008-01-13 à 21:08, Fletcher T. Penney a écrit : It appears that the _EncodeAmpsAndAngles routine is being run over the comments, converting & and < to the HTML markup. I tried adding & and < to $g_escape_table, and then protecting them. This seemed to work, but caused other problems an

Re: Possible bug in handling of HTML comments

So, another example: Test & < > Test Test & < > Test produces: p>Test & < > Test Test & < > Test It appears that the _EncodeAmpsAndAngles routine is being run over the comments, converting & and < to the HTML markup. I tried adding &

Possible bug in handling of HTML comments

It appears that Markdown will process ampersands contained within HTML comments if that comment is part of a markdown paragraph, but will not when that paragraph is contained within an HTML block of it's own (and therefore ignored by Markdown.) For example: This is a markdown paragraph wit

Re: [Bug] Codeblock in _second_ line

Le 2007-10-29 à 14:19, Milian Wolff a écrit : There is already a testcase in MDTest for codeblocks in the first line, though the above is still not handled properly! Well, PHP Markdown works as expected with a code block on the first line. It doesn't work with a code block on the second li

[Bug] Codeblock in _second_ line

Take the following input and both `Markdown.pl` and PHP Markdown will fail: ~~~Input~~ Codeblock ~~~End~~~ ~~~Expected Codeblock ~~~End~~~ ~~~Actual Result~~ Codeblock ~~~End There is already a testcase in MDTest for codeblocks in the first line, though the above

Re: [Bug] PHP Markdown (Extra) generates invalid HTML for code blocks

Le 2007-09-02 à 12:32, Milian Wolff a écrit : May I ask which parser you use? I wrote my own for the rewrite of html2text.php. I just applied it as a sourceforge project, if you are interested you might have a look into it the next week. MDTest uses the DOMDocument->loadHTML function[^1] avail

Re: [Bug] PHP Markdown (Extra) generates invalid HTML for code blocks

Am Sonntag, 2. September 2007 schrieb Michel Fortin: > Le 2007-09-02 à 10:23, Milian Wolff a écrit : > > PHP Markdown v 1.0.1i and PHP Markdown Extra v 1.1.5 generate > > invalid HTML for > > code blocks > > > > Take this input: > > > > paragraph > > > > codeblock > > > > Markdown will

Re: [Possible Bug]: Additional wrapper around HTML input

Le 2007-09-02 à 8:56, Milian Wolff a écrit : Well, it's a documented limitation on the Markdown syntax page: "The only restrictions are that block-level HTML elements -- e.g. ``, ``, ``, ``, etc. -- must be separated from surrounding content by blank lines, and the start a

Re: [Bug] PHP Markdown (Extra) generates invalid HTML for code blocks

Le 2007-09-02 à 10:23, Milian Wolff a écrit : PHP Markdown v 1.0.1i and PHP Markdown Extra v 1.1.5 generate invalid HTML for code blocks Take this input: paragraph codeblock Markdown will generate: paragraph codeblock Notice the wrong position of the closing cod

[Bug] PHP Markdown (Extra) generates invalid HTML for code blocks

PHP Markdown v 1.0.1i and PHP Markdown Extra v 1.1.5 generate invalid HTML for code blocks Take this input: paragraph codeblock Markdown will generate: paragraph codeblock Notice the wrong position of the closing code tag. -- Milian Wolff http://milianw.de __

[Possible Bug]: Additional wrapper around HTML input

I hope this is not by design and not an already discussed bug. Take the following input: If this is run through Markdown a paragraph will wrap hr's numer 4-6. This behaviour can be found in both Markdown.pl and Markdown.php (I used the Dingus provid

Re: Bug: Code block after list

Waylan Limberg wrote: > IIRC, there was a recent discussion about having two blank lines force > the end of a block. > Certainly a simpler solution than others proposed here. Or is there > something obvious that I'm missing? Is it safe? While it wouldn't break any of my source, it could introduc

Re: Bug: Code block after list

On 8/4/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote: > Eg.: how do you write two consecutive lists? How do you write two > consecutive code blocks? I think code blocks would have to be an exception to the two-blank-lines-ends-anything rule, since it's pretty common to skip multiple lines in source c

Re: Bug: Code block after list

* Waylan Limberg <[EMAIL PROTECTED]> [2007-08-04 20:40]: > IIRC, there was a recent discussion about having two blank > lines force the end of a block. If implemented, that would > certainly work here and simplify all the possibilities Michel > summarized nicely. Most likely, I would then always wr

Re: Bug: Code block after list

On 8/3/07, Michel Fortin <[EMAIL PROTECTED]> wrote: This is simply because code blocks and the content of a list item with block-level content are denoted by the same thing: four space of indentation. To be able to create list items with block-level Ah, you're right. So this isn't one of the n

Re: Bug: Code block after list

IIRC, there was a recent discussion about having two blank lines force the end of a block. If implemented, that would certainly work here and simplify all the possibilities Michel summarized nicely. Most likely, I would then always wrap any code blocks in two blank lines for good measure. Certainl

Re: Bug: Code block after list

Michel Fortin wrote: > Yeah. That's pretty much exactly what I proposed last year: > Ahh, forgot that. +1, then. > Also, did anyone notice the syntax John used in this email to denote > code examples? >

Re: Bug: Code block after list

Le 2007-08-04 à 7:46, Lou Quillio a écrit : When composing email I nearly always bracket a code block with some kind of visual line, top and bottom. ~~~ I am preformatted { don't interpret me; } Everything in here is to be taken literally. ~~

Re: Bug: Code block after list

Am Samstag, 04. August 2007 schrieb Lou Quillio: > Michel Fortin wrote: > > it is necessary to interpret indented content after a list item as the > > continuation of the content of that particular item. > > Ack! Of course. Didn't see it because my actual case is a lot more > complicated. > > Les

Re: Bug: Code block after list

Michel Fortin wrote: > it is necessary to interpret indented content after a list item as the > continuation of the content of that particular item. Ack! Of course. Didn't see it because my actual case is a lot more complicated. Less-liberal list indenting would be bad, so the only solution is

Re: Bug: Code block after list

Le 2007-08-03 à 11:16, Lou Quillio a écrit : Input: Some text. * I am * a list I, on the other hand, am a code block. My lines are indented four spaces. More text. This

Re: Bug: Code block after list

Jacob Rus wrote: > Unfortunately there has been stiff (not particularly > logical IMO) resistance to formalizing markdown on this mailing list. I'm not religious about that, but this one did surprise me because I figured code blocks were tokenized early, since they only get a few entity transforms

Re: Bug: Code block after list

Lou Quillio wrote: Maybe this has been reported before, but I can't find it in the archives. Yes, at the very least Michael Sheets has this somewhere in his list of broken edge cases. There are dozens of such problems at the margins in current Markdown, mostly stemming from its lack of a rea

Bug: Code block after list

Maybe this has been reported before, but I can't find it in the archives. A code block immediately following an ordered or unordered list breaks both the list and the code block. Badly. Tab or spaces for the block don't matter, legal indentation variants of the list don't matter. Tried a bunch

[jo...@debian.org: Bug#405058: does not properly support nested divs in inlined html]

Howdy, The attached bug report was sent to the Debian bug tracking system. If you please preserve the CC to [EMAIL PROTECTED] on any responses? - Forwarded message from Joey Hess <[EMAIL PROTECTED]> - From: Joey Hess <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[

Re: possible bug in PHP Markdown implementation of footnotes, as well as request for standardized XHTML output

Le 20 sept. 2006 à 17:58, Fletcher T. Penney a écrit : I am glad to see support for footnotes working its way into other implementations of Markdown! And I'm glad to see there is interest in footnotes. :-) Issue # 1. There appears to be a bug in the footnote parser that causes mat

possible bug in PHP Markdown implementation of footnotes, as well as request for standardized XHTML output

I am glad to see support for footnotes working its way into other implementations of Markdown! However, I have a couple of issues. Issue # 1. There appears to be a bug in the footnote parser that causes material following the footnote to be included as part of the footnote. For example

Re: Possible bug in Markdown.pl with `<<` handling

Michel Fortin wrote: But that does not mean it's the right thing to do. Does `<>` looks like a tag? I suppose it's debatable. To me it looks more like French quotes. My suggestion is just use «», and we can avoid this problem altogether. :) -Jacob ___

Re: Possible bug in Markdown.pl with `<<` handling

Le 13 sept. 2006 à 13:57, John Gruber a écrit : This is perhaps a contrived example, but if someone put this in a Markdown document: <> they might reasonably expect the output to be: not: <> Except that Markdown currently converts that to: <> which mak

Re: Possible bug in Markdown.pl with `<<` handling

Fletcher T. Penney <[EMAIL PROTECTED]> wrote on 9/13/06 at 6:29 AM: > Perhaps I am ignoring something obvious - but when does `<<` ever > occur in XHTML? Shouldn't it be a safe assumption that Markdown > should convert any string of multiple `<`'s in a row into `<`'s? This is perhaps a contr

Re: Possible bug in Markdown.pl with `<<` handling

Le 13 sept. 2006 à 6:29, Fletcher T. Penney a écrit : Perhaps I am ignoring something obvious - but when does `<<` ever occur in XHTML? Shouldn't it be a safe assumption that Markdown should convert any string of multiple `<`'s in a row into `<`'s? `<<` doesn't occur in valid HTML or XHTML.

Re: Possible bug in Markdown.pl with `<<` handling

* Michel Fortin <[EMAIL PROTECTED]> [2006-09-13 04:20]: > (Assuming you meant ``, or ``.) Yes, that’s what I meant. * John Gruber <[EMAIL PROTECTED]> [2006-09-13 06:35]: > Yeah, either way you're "escaping" it, and `\<` is easier and > prettier than `<`. No doubt. Just saying it’s alr

Re: Possible bug in Markdown.pl with `<<` handling

On Sep 13, 2006, at 12:28 AM, John Gruber wrote: Michel Fortin <[EMAIL PROTECTED]> wrote on 9/11/06 at 6:39 PM: Your example illustrate the problem quite well, but is it really a bug? How can Markdown tell isn't really a tag? What if you had <>? In fact, Markdown treat a

Re: Possible bug in Markdown.pl with `<<` handling

Michel Fortin <[EMAIL PROTECTED]> wrote on 9/12/06 at 9:59 PM: > But still, I think it would be more natural if `<` could be escaped > without an HTML entity reference. Yeah, either way you're "escaping" it, and `\<` is easier and prettier than `<`. -J.G. __

Re: Possible bug in Markdown.pl with `<<` handling

Michel Fortin <[EMAIL PROTECTED]> wrote on 9/11/06 at 6:48 PM: > Your first suggestion, escaping `<`, doesn't work as Markdown doesn't > consider `<` to be an escapable character. I'd be interesting if it > did however, as it is currently impossible to write anything like a > outside a code

Re: Possible bug in Markdown.pl with `<<` handling

Michel Fortin <[EMAIL PROTECTED]> wrote on 9/11/06 at 6:39 PM: > Your example illustrate the problem quite well, but is it really a > bug? How can Markdown tell isn't really a tag? What if you > had <>? In fact, Markdown treat as if it was a > tag and leave it

Re: Possible bug in Markdown.pl with `<<` handling

Le 11 sept. 2006 à 23:27, A. Pagaltzis a écrit : * Michel Fortin <[EMAIL PROTECTED]> [2006-09-12 00:50]: Your first suggestion, escaping `<`, doesn't work as Markdown doesn't consider `<` to be an escapable character. I'd be interesting if it did however, as it is currently impossible to writ

Re: Possible bug in Markdown.pl with `<<` handling

* Michel Fortin <[EMAIL PROTECTED]> [2006-09-12 00:50]: > Your first suggestion, escaping `<`, doesn't work as Markdown > doesn't consider `<` to be an escapable character. I'd be > interesting if it did however, as it is currently impossible > to write anything like a outside a code span or a

Re: Possible bug in Markdown.pl with `<<` handling

Le 11 sept. 2006 à 17:54, Jacob Rus a écrit : I'm just wondering… is there any case where you want `<>` not in a monospace font? That has to be some kind of codeword, and I can't imagine it coming up in regular prose. The double less-than sign `<<` is a way to approximate double angle qu

Re: Possible bug in Markdown.pl with `<<` handling

<>. As is << this>>/. Your example illustrate the problem quite well, but is it really a bug? How can Markdown tell isn't really a tag? What if you had <>? In fact, Markdown treat as if it was a tag and leave it alone as it should according to John&#x

Re: Possible bug in Markdown.pl with `<<` handling

dn't screw it up either. That's the whole point of converting any `<` Markdown doesn't understand into `<`. In this instance, the regexp misses one. Are you suggesting that Markdown users not be allowed to use `<<` at all? (The trailing `>>` is not nec

Re: Possible bug in Markdown.pl with `<<` handling

Fletcher T. Penney wrote: It appears that "double angles" are not properly converted when they are not in code blocks, if there is not a space following the second `<`. For example: This is not handled <>. becomes: This is not handled <>. I'm just wondering… is there any case whe

Possible bug in Markdown.pl with `<<` handling

It appears that "double angles" are not properly converted when they are not in code blocks, if there is not a space following the second `<`. For example: This is not handled <>. But this <>. As is << this>>/. becomes: This is not handled <>.

Re: numbered list bug in markdown.pl?

John Gruber wrote: A. Pagaltzis <[EMAIL PROTECTED]> wrote on 7/13/06 at 5:45 AM: But I don't have documents any that rely on tiny indentation to mark up nested lists. There is nothing in the docs that specifies the behaviour of this case in detail. In fact I was surprised by the actual behaviour

Re: numbered list bug in markdown.pl?

Hi John, * John Gruber <[EMAIL PROTECTED]> [2006-07-20 21:45]: > A. Pagaltzis <[EMAIL PROTECTED]> wrote on 7/13/06 at 5:45 AM: > >So I would argue that there is room to tweak the indentation > >rules, but none to tweak the numbering requirements. I would > >instead suggest that to start a nested l

Re: numbered list bug in markdown.pl?

A. Pagaltzis <[EMAIL PROTECTED]> wrote on 7/13/06 at 5:45 AM: > But I don’t have documents any that rely on tiny indentation to > mark up nested lists. There is nothing in the docs that specifies > the behaviour of this case in detail. In fact I was surprised by > the actual behaviour. > > So I w

Re: numbered list bug in markdown.pl?

llowed by one or more spaces or a tab. That would indicate that three spaces or less would never create a sublist. IMHO all those people who have been using only one space for a sublist are just being lazy and when the bug is fixed their laziness will bit them back. Perhaps that sounds harsh, but as A

Re: numbered list bug in markdown.pl?

aces or a tab. That would indicate that three spaces or less would never create a sublist. IMHO all those people who have been using only one space for a sublist are just being lazy and when the bug is fixed their laziness will bit them back. Perhaps that sounds harsh, but as A. Pagaltzis said: On

Re: numbered list bug in markdown.pl?

* Michel Fortin <[EMAIL PROTECTED]> [2006-07-13 03:50]: > For example would yeild two sublists: > > 1. List item > 10. Sublist item > 20. List item > 2. Sublist item That is hard to parse even visually for a human. I think requiring more indentation won’t make Markdown unduly h

Re: numbered list bug in markdown.pl?

Le 12 juil. 2006 à 20:33, Jacob Rus a écrit : Yes, I realize it's picking things up as multiple indentation levels, but I offer that this is a bug, and that python markdown has this right. Having numbers of numbered lists right-aligned seems like a legitimate method of writing th

Re: numbered list bug in markdown.pl?

example and run it through both to see what you get. Yes, I realize it's picking things up as multiple indentation levels, but I offer that this is a bug, and that python markdown has this right. +1 as to this is a bug (or the spec should be explicit) -- Joseph Lorenzo Hall PhD S

Re: numbered list bug in markdown.pl?

indentation levels, but I offer that this is a bug, and that python markdown has this right. Having numbers of numbered lists right-aligned seems like a legitimate method of writing them in plain text, and when there is *less* indentation, having a sublist formed is counter-intuitive to me.

Re: numbered list bug in markdown.pl?

Rus <[EMAIL PROTECTED]> wrote: > Hi, > > I'm getting what I believe to be a bug. If I put the following in markdown: > >1. This is a numbered list >2. Blah > 9. This is another list item > 10. Ok, weird bug here > 11. It's really bothering

Re: numbered list bug in markdown.pl?

I'm guessing it's because you have different indent levels. Try removing the spaces before 1-9. On 7/7/06, Jacob Rus <[EMAIL PROTECTED]> wrote: Hi, I'm getting what I believe to be a bug. If I put the following in markdown: 1. This is a numbered list 2. Blah 9.

numbered list bug in markdown.pl?

Hi, I'm getting what I believe to be a bug. If I put the following in markdown: 1. This is a numbered list 2. Blah 9. This is another list item 10. Ok, weird bug here 11. It's really bothering me And when I run it through markdown.pl 1.01 I get out the following: This is

Re: Bug: invalid nesting of inline markup across link labels

A. Pagaltzis <[EMAIL PROTECTED]> wrote on 5/2/06 at 9:15 PM: > there’s a bug in Markdown.pl: > > [foo*bar](#) [baz*quux](#) > > This expands to the following: > > foobar bazquux > > Those `*` should either be disregarded or the tags should nest > co

Re: Bug: invalid nesting of inline markup across link labels

For comparison, Python-Markdown[1] results in this: foo*bar baz*quux [1]: http://www.freewisdom.org/projects/python-markdown/ On 5/2/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote: Hi John, there's a bug in Markdown.pl: [foo*bar](#) [baz*quux](#) This expands to th

Bug: invalid nesting of inline markup across link labels

Hi John, there’s a bug in Markdown.pl: [foo*bar](#) [baz*quux](#) This expands to the following: foobar bazquux Those `*` should either be disregarded or the tags should nest correctly: 1.foo*bar baz*quux 2.foobar bazquux Of course, the second option is a lot more complex to