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 :-)
Bug report on Python-Markdown issue list:
https://github.com
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 that nothing seems
or is this a bug?
Regards,
Chris
smime.p7s
Description: S/MIME Cryptographic Signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss
On Fri, Mar 18, 2011 at 1:54 PM, John MacFarlane j...@berkeley.edu 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
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_(file_format) ZIP
(file format
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
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
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 and
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
So, another example:
Test !-- Test sd -- Test
pTest!-- Test sd -- Test/p
produces:
pTest amp; lt; !-- Test amp; lt; sd -- Test/p
pTest!-- Test sd -- Test/p
It appears that the _EncodeAmpsAndAngles routine is being run
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
Take the following input and both `Markdown.pl` and PHP Markdown will fail:
~~~Input~~
Codeblock
~~~End~~~
~~~Expected
precode
Codeblock/pre/code
~~~End~~~
~~~Actual Result~~
pCodeblock/p
~~~End
There is already a testcase in MDTest for codeblocks in the first
I hope this is not by design and not an already discussed bug.
Take the following input:
hr id=foo /
hr id=foo
hr id=foo/
hr id=foo /
hr id=foo
hr id=foo/
If this is run through Markdown a paragraph will wrap hr's numer 4-6. This
behaviour can be found in both
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:
pparagraph/p
precodecodeblock
/pre/code
Notice the wrong position of the closing code tag.
--
Milian Wolff
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]
Michel Fortin wrote:
Yeah. That's pretty much exactly what I proposed last year:
http://six.pairlist.net/pipermail/markdown-discuss/2006-October/000349.html
Ahh, forgot that. +1, then.
Also, did anyone notice the syntax John used in this email to denote
code examples?
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
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
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.
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.
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 [EMAIL PROTECTED
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 properly isn't really a tag? What if you
had img src=? In fact, Markdown treat properly
* Michel Fortin [EMAIL PROTECTED] [2006-09-13 04:20]:
(Assuming you meant `lt;tag`, or `lt;taggt;`.)
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 `lt;`.
No doubt. Just saying it’s
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:
?php print p;?
they might reasonably expect the output to be:
p
not:
lt;lt;?php print p;?gt;gt;
Except that Markdown currently converts that
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 properly.
But this is.
As is this/.
becomes:
pThis is not handled
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 would
Hi John,
there’s a bug in Markdown.pl:
[foo*bar](#) [baz*quux](#)
This expands to the following:
pa href=#fooembar/a a href=#baz/emquux/a/p
Those `*` should either be disregarded or the tags should nest
correctly:
1.pa href=#foo*bar/a a href=#baz*quux/a/p
2.pa href=#fooembar
27 matches
Mail list logo
