Re: A bug or an undocumented feature?

[Alan Hogan]

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 to change.

Alan

On Dec 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/waylan/Python-Markdown/issues/64
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

re: A bug or an undocumented feature?

[Bowerbird]

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___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: A bug or an undocumented feature?

[Spencer Wysinger]

I went and looked at the report and am sad to see that people always use that 
"remaining pure to Markdown.pl" argument.  :(

I'd like to find a single person who *depends* on peculiarities like that and 
not just anticipates and intentionally works around them when authoring their 
documents.

It's stuff like that which makes it hard to sell Markdown to some of my 
colleagues. IMHO, as places like Stackoverflow and GitHub implement "non-pure" 
Markdown parsers that actually work how every person knows it should work, the 
better off we'll all be. Think 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 :-)
> 
> Bug report on Python-Markdown issue list:
> https://github.com/waylan/Python-Markdown/issues/64
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net (mailto:Markdown-Discuss@six.pairlist.net)
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
> 



___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

A bug or an undocumented feature?

[yegle]

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-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug using inline code blocks in nested lists?

[Fletcher T. Penney]

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 as I test my changes to
peg-markdown to see what I've broken

F-

-- 
Fletcher T. Penney
fletc...@fletcherpenney.net
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug using inline code blocks in nested lists?

[John MacFarlane]

+++ Christian Spann [Mar 18 11 16:36 ]:
> 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?

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 maintained?  The versions of pandoc
and peg-markdown there are a couple of years old.

John
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Bug using inline code blocks in nested lists?

[Christian Spann]

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 Cryptographic Signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug?

[Waylan Limberg]

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) - Wikipedia, the free encyclopedia")
>
>  gets rendered by Markdown 1.01 as:
>
[snip]

According to Babelmark [1] its fixed in 1.02b8. Although I see a few
other distributions get this wrong too. Thanks for the report.


[1]: 
http://babelmark.bobtfish.net/?markdown=%5BZIP+archives%5D%28http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FZIP_%28file_format%29+%22ZIP+%28file+format%29+-+Wikipedia%2C+the+free+encyclopedia%22%29&normalize=on



-- 

Waylan Limberg
[EMAIL PROTECTED]
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Bug?

[Mark Eli Kalderon]

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 as:

http://en.wikipedia.org/wiki/ZIP_(file_format">ZIP  
archives "ZIP (file format) - Wikipedia, the free encyclopedia")


Shouldn't it be, instead:

http://en.wikipedia.org/wiki/ZIP_(file_format" title="ZIP  
(file format) - Wikipedia, the free encyclopedia">ZIP archives


There are two problems:

1. losing the final paren in the URL
2. losing the title info

All the best, Mark
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Possible bug in handling of HTML comments

[Tomas Doran]

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 slow, and very very hard to read.


IMNSHO the *correct* way to implement Markdown, is very much to build  
a parse tree - which I believe is what the python and ruby guys have  
done... You'd not have to do this sort of nasty hacking if you did  
that approach right, and it should be a shedload quicker than doing a  
zlilion md5 sums (not to mention more flexible, etc).


I'm planning to get there, or at least try to once I've finished  
consolidating the CPAN implementations:


http://svn.kulp.ch/cpan/text_multimarkdown/trunk/Todo
http://search.cpan.org/~bobtfish/Text-Markdown-1.0.5/lib/Text/ 
Markdown.pm
http://search.cpan.org/~bobtfish/Text-MultiMarkdown-1.0.7/lib/Text/ 
MultiMarkdown.pm



I will add this to the next version of MultiMarkdown as well.


I'm actively developing the CPAN modules - how much will it take to  
convince you to merge what you're doing with what I'm doing?


My code currently passes all of the MultiMarkdown testsuite that  
MultiMarkdown passes, and all of the Markdown testsuite. (Disclaimer  
- except the email hashing, I removed the call to srand() that  
nobbled the random number generator each time you called markdown,  
and haven't done anything smart to make the tests predictable yet).


The stuff in MultiMarkdown to do xsl transforms to produce latex is  
really neat, and I really think that it'd be better for everyone if  
there could be 'one true version' of Markdown written in perl. Thoughts?


Cheers
Tom

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Possible bug in handling of HTML comments

[Fletcher T. Penney]

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: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 is  
clearly not a viable solution.


So it looks like there would have to be a specific mechanism in  
place for leaving comments alone, am I correct?




Yep, totally correct.

I'm about to add this into Text::MultiMarkdown (will be in the 1.0.8  
release on CPAN in a week or two) - I've attached the diff that I've  
made to make this work (and test it).


Please yell if you can think of a better / prettier / quicker way of  
doing it? ;)


It's another case that shows up how building a parse tree would be a  
better approach (as we wouldn't need to do, then undo the encoding)  
- but what I have appears to work right now...


Cheers
Tom

< 
ampsandanglesinhtmlcomments 
.diff>___

Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss




--
Fletcher T. Penney
[EMAIL PROTECTED]

Always remember you are nothing more than a collection of
complementary chemicals worth not more than $5.00
- Seen on the internet



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Possible bug in handling of HTML comments

[Tomas Doran]

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 is  
clearly not a viable solution.


So it looks like there would have to be a specific mechanism in  
place for leaving comments alone, am I correct?




Yep, totally correct.

I'm about to add this into Text::MultiMarkdown (will be in the 1.0.8  
release on CPAN in a week or two) - I've attached the diff that I've  
made to make this work (and test it).


Please yell if you can think of a better / prettier / quicker way of  
doing it? ;)


It's another case that shows up how building a parse tree would be a  
better approach (as we wouldn't need to do, then undo the encoding) -  
but what I have appears to work right now...


Cheers
Tom



ampsandanglesinhtmlcomments.diff
Description: Binary data
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Possible bug in handling of HTML comments

[Michel Fortin]

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 and is  
clearly not a viable solution.


So it looks like there would have to be a specific mechanism in  
place for leaving comments alone, am I correct?



PHP Markdown deals with this correctly since I added span-level  
hashes and use them to protect tags, comments, escapes, and  
everything that must be left alone. Perhaps someone ought to backport  
that system to Perl.



Michel Fortin
[EMAIL PROTECTED]
http://michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Possible bug in handling of HTML comments

[Fletcher T. Penney]

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 & and < to $g_escape_table, and then protecting them.   
This seemed to work, but caused other problems and is clearly not a  
viable solution.


So it looks like there would have to be a specific mechanism in place  
for leaving comments alone, am I correct?



Thanks!

Fletcher


On Jan 13, 2008, at 8:06 PM, Fletcher T. Penney wrote:

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 with a comment that *will* be processed  





It seems to me that the & within a comment should be ignored by  
Markdown and not converted to &



The reason this is important for me, is that I am experimenting with  
using HTML comments as a means to pass text that should be ignored  
by MultiMarkdown (e.g. to allow raw LaTeX, etc).  But some of the  
comments *are* being processed, which screws them up.



Thanks for any insight, and ideas on how to fix this!


Fletcher Penney


--
Fletcher T. Penney
[EMAIL PROTECTED]

Without question, the greatest invention in the history of mankind
is beer. Oh, I grant you that the wheel was also a fine invention,
but the wheel does not go nearly as well with pizza.
- Dave Barry





--
Fletcher T. Penney
[EMAIL PROTECTED]

Without question, the greatest invention in the history of mankind
is beer. Oh, I grant you that the wheel was also a fine invention,
but the wheel does not go nearly as well with pizza.
- Dave Barry



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Possible bug in handling of HTML comments

[Fletcher T. Penney]

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 with a comment that *will* be processed  





It seems to me that the & within a comment should be ignored by  
Markdown and not converted to &



The reason this is important for me, is that I am experimenting with  
using HTML comments as a means to pass text that should be ignored by  
MultiMarkdown (e.g. to allow raw LaTeX, etc).  But some of the  
comments *are* being processed, which screws them up.



Thanks for any insight, and ideas on how to fix this!


Fletcher Penney


--
Fletcher T. Penney
[EMAIL PROTECTED]

Without question, the greatest invention in the history of mankind
is beer. Oh, I grant you that the wheel was also a fine invention,
but the wheel does not go nearly as well with pizza.
- Dave Barry



smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: [Bug] Codeblock in _second_ line

[Michel Fortin]

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 line though.  
I'm adding a test right now so that I don't forget it when I work on  
the next release.



Michel Fortin
[EMAIL PROTECTED]
http://michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

[Bug] Codeblock in _second_ line

[Milian Wolff]

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 is still not handled properly!
-- 
Milian Wolff
http://milianw.de
OpenPGP key: CD1D1393


signature.asc
Description: This is a digitally signed message part.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Michel Fortin]

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] available in PHP 5:



It produces a DOM, which can be normalized for whitespace, then  
reserialized as HTML and compared with the expected result file. The  
upside is that it's pretty fast. The downside is that it ignores  
misnested tags like this one.


I think I will use the XML parser instead. That will work, except for  
a few cases where non-XHTML HTML blocks are passed unchanged through  
Markdown.



[^1]: PHP 5 DOM functions, including HTML parsing, are based on libxml2.


Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Milian Wolff]

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 generate:
> >
> > paragraph
> >
> > codeblock
> > 
> >
> > Notice the wrong position of the closing code tag.
>
> Oh my! That's a typing error, and it did not fail the testsuite!
>
> I said previously that the HTML normalizer in MDTest wasn't quite
> optimal (although better than Tidy) and that's why: it doesn't catch
> this kind of misnested tags. Otherwise I'd have got failed tests
> everywhere. Perhaps it's time MDTest uses its own stricter HTML
> parser instead of the too forgiving parser in PHP 5.
>
> I'll fix that promptly, thanks for that report.

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.


-- 
Milian Wolff
http://milianw.de
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Michel Fortin]

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 and end tags of the block  
should not be indented with tabs or spaces."


"hr" is a block-level element, but you have not separated them by a  
blank line.


This is a "designed" limitation to simplify the parser. It doesn't  
mean a parser shouldn't do better, and I believe John is trying to  
improve Markdown.pl to remove some limitations like this one.




Interesting is, that Markdown Extra handles this correctly.


Indeed, Markdown Extra's HTML block parser is much better at that  
than PHP Markdown's or the one in Markdown.pl.



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[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 generate:

paragraph

codeblock


Notice the wrong position of the closing code tag.


Oh my! That's a typing error, and it did not fail the testsuite!

I said previously that the HTML normalizer in MDTest wasn't quite  
optimal (although better than Tidy) and that's why: it doesn't catch  
this kind of misnested tags. Otherwise I'd have got failed tests  
everywhere. Perhaps it's time MDTest uses its own stricter HTML  
parser instead of the too forgiving parser in PHP 5.


I'll fix that promptly, thanks for that report.


Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Milian Wolff]

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
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

[Possible Bug]: Additional wrapper around HTML input

[Milian Wolff]

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 provided on the project pages).

Interesting is, that Markdown Extra handles this correctly.

PS: The above input is a snippet from `MDTest/markdown.mdtest/Inline HTML 
(Simple).text`
-- 
Milian Wolff
http://milianw.de
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

[Lou Quillio]

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
introduce a sloppiness penalty, though I'm not sure for whom.
Mainstream CMS implementations come to mind.  Also, the apps that
transform _to_ Markdown would need to check themselves.

If safe, I think two linefeeds forcing a block close is good.  New
users often expect that behavior, anyway.  We probably all expected
it on first go.

Nevertheless, this is not *necessarily* the same issue as addressing
the code-block syntax weakness with a sturdier option.

Code blocks are an important and common element that rate an
optional, unindented, unambiguous syntax, because misrendering can
cause real-world damage.  There's a strong plain text convention --
and it ain't four-space indents.

Hey, I like the tab or indent thing.  It's clever.  But it's also
wobbly, and makes guys I work with nervous.  Best answer I've got
is, "Yeah, but isn't the indent thing cute?"

Cute don't play.  Nobody understands this design choice.  Too clever
by half, IMO.

LQ
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

[John Fraser]

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 code.

Didn't John Gruber mention a possible return to the colon syntax for
code blocks?  I have mixed feelings about that, but it would clarify a
lot of this stuff.

- John Fraser
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

[A. Pagaltzis]

* 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 wrap any
> code blocks in two blank lines for good measure.
> 
> Certainly a simpler solution than others proposed here. Or is
> there something obvious that I'm missing?

No. And I say that this solution is still better than adding an
alternative code block syntax, because while the code block
syntax would address the “new paragraph in a list item, or code
block following a list?” ambiguity, there are more ambiguities
very much like that one.

Eg.: how do you write two consecutive lists? How do you write two
consecutive code blocks?

Note, however, that the “two empty lines end a block” rule only
works at the top-most level, so these ambiguities would continue
to exist in nested lists and code blocks.

Regards,
-- 
Aristotle Pagaltzis // 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

[Jacob Rus]

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 nasty edge-cases, my mistake. :)

Waylan Limberg wrote:
> 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 > [...]

>
> Certainly a simpler solution than others proposed here. Or is there
> something obvious that I'm missing?

Nope, the two blank lines = break out of a block solution still sounds 
great to me.


-Jacob

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

[Waylan Limberg]

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.

Certainly a simpler solution than others proposed here. Or is there
something obvious that I'm missing?

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
> content, it is necessary to interpret indented content after a list
> item as the continuation of the content of that particular item. This
> creates the impossibility to create a code block immediately
> following a list, but the other option would be the impossibility of
> having block-level content (like paragraphs) inside a list item.
>
> This has been reported a couple of time already. The current
> workaround is to insert an HTML comment, unindented, between the list
> and the code block. That's clearly not optimal however.
>
>
> Michel Fortin
> [EMAIL PROTECTED]
> http://www.michelf.com/
>
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>


-- 

Waylan Limberg
[EMAIL PROTECTED]
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

[Lou Quillio]

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?
> 

Everybody does it, because everybody needs it.  ;)

I've personally drunk a lot of Markdown Kool-Aid, but I think the
list-continuation -> code block conflict is only an edge case to
fanboys.

The problem is that the indented code block syntax -- while a nice
bit of magic -- is too flimsy in too many cases.  List continuation
is an example of that weakness, not a reminder that "you can't have
everything".

I think the need for a second, unambiguous code block syntax won't
go away.

LQ
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

[Michel Fortin]

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.
~~~

Block start, block end.  No guessing.


Yeah. That's pretty much exactly what I proposed last year:



Also, did anyone notice the syntax John used in this email to denote  
code examples?




Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

[Milian Wolff]

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.
>
> Less-liberal list indenting would be bad, so the only solution is to
> insert _something_, and an HTML comment is the most innocuous thing.
>  Okay.  I get it.
>
> I wonder if an **optional**, explicit delimiter for code blocks
> would be so bad.  The four-space indent is fine, but it's not
> _great_.  It sometimes feels ... fragile.
>
> 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.
> ~~~
>
> Block start, block end.  No guessing.
>
> LQ

This was already discussed in great detail. Afaik the result was just to use 
HTML. So instead of writing all these `~`, just do this: 


I am preformatted {
don't interpret me;
}
Everything in here is to be
taken literally.


If I'm mistaken and this was not the proposed solution, please point it out.
-- 
Milian Wolff
http://milianw.de
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

[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.

Less-liberal list indenting would be bad, so the only solution is to
insert _something_, and an HTML comment is the most innocuous thing.
 Okay.  I get it.

I wonder if an **optional**, explicit delimiter for code blocks
would be so bad.  The four-space indent is fine, but it's not
_great_.  It sometimes feels ... fragile.

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.
~~~

Block start, block end.  No guessing.

LQ
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

[Michel Fortin]

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 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  
content, it is necessary to interpret indented content after a list  
item as the continuation of the content of that particular item. This  
creates the impossibility to create a code block immediately  
following a list, but the other option would be the impossibility of  
having block-level content (like paragraphs) inside a list item.


This has been reported a couple of time already. The current  
workaround is to insert an HTML comment, unindented, between the list  
and the code block. That's clearly not optimal however.



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

[Lou Quillio]

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.

Guess I need to look at the source.  Another exciting Friday night!  ;)

LQ

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Bug: Code block after list

[Jacob Rus]

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 real 
grammar/parser.  Unfortunately there has been stiff (not particularly 
logical IMO) resistance to formalizing markdown on this mailing list.


-Jacob Rus

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Bug: Code block after list

[Lou Quillio]

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 of casual workarounds,
extra newlines, etc., but no joy.  Needs explicit  --
which also fixes the preceding list, however Markdown then wraps the
 block in a paragraph.  PHP Markdown Extra does not.

Reproducible in current Markdown, PHP Markdown Extra, and Maruku.

LQ


Input:


Some text.

  *  I am
  *  a list

I, on the other hand, am a code block.  My lines are
indented four spaces.

More text.



Output:


Some text.


I am
a list

I, on the other hand, am a code block.  My lines are
indented four spaces.


More text.



___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Matt Kraai]

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]>
Subject: Bug#405058: does not properly support nested divs in inlined html
Date: Sat, 30 Dec 2006 14:13:04 -0500
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
UNPARSEABLE_RELAY autolearn=ham version=3.1.7

Package: markdown
Version: 1.0.1-6
Severity: normal

[EMAIL PROTECTED]:~>cat foo



foo



[EMAIL PROTECTED]:~>markdown foo



foo





-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages markdown depends on:
ii  perl  5.8.8-7Larry Wall's Practical Extraction 

markdown recommends no packages.

-- no debconf information

-- 
see shy jo



- End forwarded message -

-- 
Matt   http://ftbfs.org/
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Michel Fortin]

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 material following the footnote to be included as part of  
the footnote. For example:


Adam McMaster already signaled this bug at the start of this thread  
and has found a clever workaround until I fix it which is to put a  
comment just after the footnote, before the new content.



Issue # 2.  I would like to work towards a single consensus output  
format for the footnote syntax as well --- MultiMarkdown and PHP  
Markdown should have the same output format for compatibility reasons.


I agree. But I think the scope for that problem goes a lot further  
than Markdown and its implementations. Maybe it'd be a good idea to  
make a microformat for footnotes, and try to standardise it through  
microformats.org.


I'm not convinced there is a real need to have the exact same  
resulting markup however. As long as the output is in a format you  
can parse easily to extract footnote content and find reference  
markers in the text, it'd be fine by me.


That doesn't mean we should make things different just for the sake  
of it either. But I have no problem with different implementations,  
with different goals, doing different things. There is value in variety.



1. MultiMarkdown used div's, PHP Markdown uses an ordered list.  It  
doesn't much matter, as long as there is a way for an XSLT parser  
to reliable identify what constitutes each footnote.  I suppose one  
potential problem with the ordered list would be the inability to  
set an arbitrary number for the first footnote, but in actuality  
neither system could take advantage of it at the moment.  It's  
worth considering, but I am not sure there is an overwhelming  
reason to choose one over the other.  Any thoughts from others?


About arbitrary footnote numbers, I don't think many people need  
that. Those that do will probably want something integrated with a  
pagination system, which is way beyond what we should care at the  
moment. But I think it proves my previous point: no single markup is  
going to satisfy everyone's needs.



2. Reverse links should be from the footnote number, or from the  
↩ symbol, in both syntaxes.  Again, I don't see an  
overwhelming reason to choose one over the other.  I can easily  
modify MultiMarkdown to use the ↩ symbol if that is the  
consensus opinion.


As you said, they're both fine output. I'm following what John's  
doing because that's what I've always done with PHP Markdown.


But I don't see a necessity for all implementations to have the same  
output. As long as the markup allows the identification of footnotes  
and of their reference markers -- so that it can be changed to  
another format for instance -- it's fine by me.



3. Same thing goes for the syntax to choose footnote related id  
tags.  They can be whatever, but should be consistent.


It could be a good idea if there was some sort of convention between  
Markdown implementations about how to generate the id. The reason  
being that if someone switches implementation, it would be preferable  
that it does not break any external bookmark to a footnote.


That said, it probably wouldn't be a good idea to rely on the id  
attribute staying the same too much either. There are good reasons to  
change the generated id, adding an entry-specific prefix for a blog  
which may display more than one entry per page for instance.



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Fletcher T. Penney]

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:


< Example Section >
## Metadata ##

First, take a look at the overall structure of the document.  At the  
very beginning is metadata, including a title, author, keywords,  
copyright information, etc.  Where possible, this metadata is put to  
appropriate use, otherwise it is stored in a format designed to be  
easily read and minimally distracting:


* In plain text and XHTML snippets[^snippets], it is located at the  
top of the document.


* In a full XHTML document, is located in the `` section, and  
the title and CSS metadata, if present, are used appropriately.


* In a PDF generated from my XSLT files, metadata is used to generate  
the appropriate fields (title, author, keywords) in the PDF itself.   
Some PDF readers will let you examine this data.  Additionally, the  
title, subtitle, author, and copyright are placed at the beginning of  
the document.


There are a lot of standard metadata keys that can be used, or you  
can create your own and use them as you see fit.  Definitely a  
powerful feature.


[^snippets]: An XHTML snippet is my terminology for XHTML code that  
does not include the ``, ``, and `` tags.  Most  
browsers will display it properly, but it is not a complete XHTML  
document.  Without a `` section there is nowhere to put metadata 
(e.g. there is no ``).



## Structure ##

The next thing to look at is the overall structure of the document.   
You can visualize a Markdown document as an outline, with different  
sections and different levels within those sections.  Based on your  
output format, these can be used to generate headers, or sections, or  
even chapters.  It's all based on what tools you use to process the  
XHTML output.


Even within the XHTML document, however, you can make use of this  
structure to allow easy navigation within the document.  You can link  
directly to the [Introduction][], for instance.  And if you are  
creating a PDF, it will contain a hierarchy of section names that you  
can use to allow easy navigation, if your PDF reader supports this  
function.


Link to [bob][].



When I try this, the footnote contains the expected portion through  
the first paragraph of the following section of text (i.e. the first  
paragraph of `Structure`.



Issue # 2.  I would like to work towards a single consensus output  
format for the footnote syntax as well --- MultiMarkdown and PHP  
Markdown should have the same output format for compatibility reasons.


The current PHP output for the above (after it gets fixed) will be:






	An XHTML snippet is my terminology for XHTML code that does not  
include the <html>, <head>, and  
<body> tags.  Most browsers will display it  
properly, but it is not a complete XHTML document.  Without a  
<head> section there is nowhere to put metadata 
(e.g. there is no <title>). href="#fnref:snippets" rev="footnote">↩






The current MultiMarkdown output is:



Footnotes:

	class="reversefootnote">1. An XHTML snippet is my terminology for  
XHTML code that does not include the <html>,  
<head>, and <body> tags.  Most  
browsers will display it properly, but it is not a complete XHTML  
document.  Without a <head> section there is  
nowhere to put metadata(e.g. there is no <title>code>).


	2.a> I guess it depends on what kind of parties you go to…





I would like to get feedback for a consensus standard (or at least  
until John decides to implement footnotes in the official Markdown  
syntax).  These are the issues that I see:


1. MultiMarkdown used div's, PHP Markdown uses an ordered list.  It  
doesn't much matter, as long as there is a way for an XSLT parser to  
reliable identify what constitutes each footnote.  I suppose one  
potential problem with the ordered list would be the inability to set  
an arbitrary number for the first footnote, but in actuality neither  
system could take advantage of it at the moment.  It's worth  
considering, but I am not sure there is an overwhelming reason to  
choose one over the other.  Any thoughts from others?


2. Reverse links should be from the footnote number, or from the  
↩ symbol, in both syntaxes.  Again, I don't see an overwhelming  
reason to choose one over the other.  I can easily modify  
MultiMarkdown to use the ↩ symbol if that is the consensus  
opinion.


3. Same thing goes for the syntax to choose footnote related id  
tags.  They can be whatever, but should be consistent.



To reiterate, I am ok with choosing to go with PHP format, 

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

[Jacob Rus]

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

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Michel Fortin]

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 makes the final output:



It doesn't really invalidate your point, it's only one more proof  
that `<<` defies everyones' expectations.



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[John Gruber]

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 contrived example, but if someone put this in a
Markdown document:

<>

they might reasonably expect the output to be:



not:

<>

We can't have it both ways. The current "if it looks like a tag,
Markdown treats it as a tag" rule seems simpler and more obvious
to me than your proposed "if it looks like a tag, it's treated as
a tag, unless the angle brackets are in a consecutive run of other
angle brackets, in which case they're all treated as literal angle
brackets" rule.

-J.G.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Michel Fortin]

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. But we are talking about  
Markdown, not HTML.


The question is how to disambiguate text from tags in Markdown?  
Currently this is very simple: if something looks like a tag, then it  
is treated as a tag. Markdown sees `<>` as a valid tag  
surrounded by `<` and `>`.


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.



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[A. Pagaltzis]

* 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 alreadz possible.

Regards,
-- 
Aristotle Pagaltzis // 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Fletcher T. Penney]

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  as if it was a
tag and leave it alone as it should according to John's syntax
description document.


Right. This is working as designed at the moment. If you want to
use `<<`, you'll just have to put spaces around it:

this << that

-J.G.


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?


Fletcher

--
Fletcher T. Penney
[EMAIL PROTECTED]

Life doesn't cease to be funny when people die any more than it  
ceases to be

serious when people laugh.
- G.B. Shaw




smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[John Gruber]

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.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[John Gruber]

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 span or a code block.

That might be reasonable.

I hate writing escapes in Markdown, because every time I need to
use one I only remember it *after* I first publish without it,
but, in cases like this, it's better to add an escape to make
something possible than to leave something as impossible.

-J.G.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[John Gruber]

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 alone as it should according to John's syntax  
> description document.

Right. This is working as designed at the moment. If you want to
use `<<`, you'll just have to put spaces around it:

this << that

-J.G.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Michel Fortin]

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 write anything like a   outside a code span or a code
block.


But there is. You just write ``, or  
``.)


But still, I think it would be more natural if `<` could be escaped  
without an HTML entity reference.



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[A. Pagaltzis]

* 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 code
> block.

But there is. You just write `
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Michel Fortin]

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  
quotes `«` in a plain ascii context, with old typewriters, and more  
importantly for people who do not know about the right key  
combinaison they have to use to type the character on their keyboard.


So I'm interested in preventing `<<` from starting a tag as it is a  
small real-world problem I have seen from time to time.


Beside that reason, `<<` can be automatically converted by PHP  
SmartyPants Typographer to proper angle quotes, so if Markdown  
disambiguate it correctly as plain characters it could be converted  
to angle-quotes automatically. And that'd be great.



My suggestion is to either escape the second `<`, as in `\< 
\>`, or else just wrap the whole thing in `\`` marks, as  
in `` `

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

[Michel Fortin]

Le 11 sept. 2006 à 17:00, Fletcher T. Penney a écrit :

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>>/.


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's syntax  
description document.


The question is: should we make an exception for the << construct? It  
wouldn't be terribly difficult.



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Fletcher T. Penney]

On Sep 11, 2006, at 5:54 PM, Jacob Rus wrote:

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.  My suggestion is to  
either escape the second `<`, as in `\<\>`, or else just  
wrap the whole thing in `\`` marks, as in `` `<Markdown shouldn't be expected to deal with such weird almost–html- 
tag things.


-Jacob



I agree that Markdown shouldn't have to "deal with" anything it  
doesn't handle, but it shouldn'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 necessary to demonstrate this bug,  
just the `<<` followed immediately by almost any non-whitespace  
character.)  I frequently use `<<` as a shorthand for "much less  
than" and it would not be inconceivable that this could end up in a  
Markdown document.



Fletcher

--
Fletcher T. Penney
[EMAIL PROTECTED]

A well adjusted person is one who makes the same mistake twice without
getting nervous.




smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Jacob Rus]

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 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.  My suggestion is to either 
escape the second `<`, as in `\<\>`, or else just wrap the 
whole thing in `\`` marks, as in `` `

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

[Fletcher T. Penney]

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 <>.

But this <>.


As is << this>>/.


The `&;t;<` causes problems with XSLT.  I suppose one could look for  
series of `<`'s and convert them all to `<`.  Is there any  
situation in which this would be the incorrect thing to do?



Fletcher


--
Fletcher T. Penney
[EMAIL PROTECTED]

I have noted that persons with bad judgment are most insistent that  
we do what they think best.

- Lionel Abel




smime.p7s
Description: S/MIME cryptographic signature
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: numbered list bug in markdown.pl?

[Jacob Rus]

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.

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 list, the marker be
required to be indented at least three spaces more than the
preceeding item.


I agree. Why three though? It "feels" like a reasonable number,
but four spaces is the magic cut-off point in all the other places
where indentation matters in Markdown.


Instead of basing the amount of indentation on the exact beginning of 
the previous item, I would prefer that each tab or 4 spaces correspond 
to one  level of indentation.  Thus


  - 0-3 spaces = top level
  - 4-7 spaces = 2nd level
  - 8-11 spaces = 3rd level, etc.

Then if an item is indented more than this, it is considered a code block.

So this:

1. a list
  2. 2nd item
 3. third item
   4. fourth item
- sublist
   - in same sublist
 - still on item 4
  5. back to top-level

turn into this:


a list
2nd item
third item
fourth item

sublist
in same sublist
still on item 4

back to top-level


instead of what we currently get:


a list

2nd item
third item
fourth item
sublist

in same sublist
still on item 4

back to top-level



Obviously this is more ragged than we hope real-life lists will be, but 
by keeping stops to 4 spaces, I think we most closely stick to John's 
official spec, and keep things as unambiguous as possible.


-Jacob Rus

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: numbered list bug in markdown.pl?

[A. Pagaltzis]

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 list, the marker be
> >required to be indented at least three spaces more than the
> >preceeding item.
> 
> I agree. Why three though?

to be conservative. Requiring three spaces is a slightly smaller
change of the newly documented behaviour than four, compared to
the existing undocumented one that someone out there *might* have
relied on.

> It "feels" like a reasonable number, but four spaces is the
> magic cut-off point in all the other places where indentation
> matters in Markdown.

Yes, in terms of clarity of rules I would prefer requiring four.

Since I can only make suggestions, I picked a conservative one.
(I admit I should have specified my reasoning further.) If you as
the one who makes the final call decree that four is the right
number, I’ll be glad about that decision.

Regards,
-- 
Aristotle Pagaltzis // 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: numbered list bug in markdown.pl?

[John Gruber]

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 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 list, the marker be
> required to be indented at least three spaces more than the
> preceeding item.

I agree. Why three though? It "feels" like a reasonable number,
but four spaces is the magic cut-off point in all the other places
where indentation matters in Markdown.

--J.G.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: numbered list bug in markdown.pl?

[Seumas Mac Uilleachan]

Waylan Limberg wrote:

On 7/12/06, Michel Fortin <[EMAIL PROTECTED]> wrote:
[snip]

Personally, I'd go the route of requiring an increasing character
count for numeric markers when they are right-aligned because I think
it is the less damaging thing to do to current Markdown text and
because it makes sense visually. The previous example would be
equivalent to this:

 1.  List item
 10. List item
 20. List item
 2.  List item

As would this:

  1. List item
 2. List item
 3. List item
  4. List item

Not perfect, as it still breaks the rule saying you can use any
number as list marker when numbers are more than one character and
right-aligned, but it is the best compromise I can think of. What do
you think?


That is how the python implementation currently works with one
exception. The fourth item would not be a sublist as it is not
indented by at least 4 spaces. The thing about enforcing at least four
spaces is that it allows right aligning numbers up to three digits
without interference. I realize many people using perl/php/other
implementations may have many documents which do not strictly indent
sublists at least four spaces though, so that is a backward
compatibility issue. However, that is the so called "undocumented
feature" which the documentation actually does not seem to support. It
says:


List markers typically start at the left margin, but may be
indented by up to three spaces. List markers must be
followed 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. Pagaltzis
said:

On 7/12/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:

I think requiring more indentation won't make Markdown
unduly harder to write but it will definitely make documents
more readable.


Which as I understand it, is the goal of markdown in the first place.



I would have to agree with this logic. I use the PHP version of markdown 
and I have always indented sublists with four spaces because that was 
how the syntax documentation said to do it and because it makes the 
unformatted text more readable. Using one space as in some of the 
examples above leads to ambiguity into what is part of teh list and what 
is supposed to be a sublist. The whole idea of markdown is to eliminate 
(or at least greatly reduce) the ambiguity of the unformatted text.


A script can be written to reformat (ie add spaces) the lists for those 
who used less than four spaces if this "bug" is fixed. But likely not by 
me :)

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: numbered list bug in markdown.pl?

[Waylan Limberg]

On 7/12/06, Michel Fortin <[EMAIL PROTECTED]> wrote:
[snip]

Personally, I'd go the route of requiring an increasing character
count for numeric markers when they are right-aligned because I think
it is the less damaging thing to do to current Markdown text and
because it makes sense visually. The previous example would be
equivalent to this:

 1.  List item
 10. List item
 20. List item
 2.  List item

As would this:

  1. List item
 2. List item
 3. List item
  4. List item

Not perfect, as it still breaks the rule saying you can use any
number as list marker when numbers are more than one character and
right-aligned, but it is the best compromise I can think of. What do
you think?


That is how the python implementation currently works with one
exception. The fourth item would not be a sublist as it is not
indented by at least 4 spaces. The thing about enforcing at least four
spaces is that it allows right aligning numbers up to three digits
without interference. I realize many people using perl/php/other
implementations may have many documents which do not strictly indent
sublists at least four spaces though, so that is a backward
compatibility issue. However, that is the so called "undocumented
feature" which the documentation actually does not seem to support. It
says:


List markers typically start at the left margin, but may be
indented by up to three spaces. List markers must be
followed 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. Pagaltzis
said:

On 7/12/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:

I think requiring more indentation won't make Markdown
unduly harder to write but it will definitely make documents
more readable.


Which as I understand it, is the goal of markdown in the first place.

--

Waylan Limberg
[EMAIL PROTECTED]
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: numbered list bug in markdown.pl?

[A. Pagaltzis]

* 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 harder to
write but it will definitely make documents more readable.

> But how is the second sublist item different from the first
> 1-10-20-2  example of this post:
> 
>  1. List item
> 10. List item
> 20. List item
>  2. List item

There is no previous item with a smaller indent.

But there is no way to avoid creating a nested list for the last
item in this example, and to me, the vertical alignment would
clearly indicates that the author did not intend that to happen.

> Personally, I'd go the route of requiring an increasing
> character count for numeric markers when they are right-aligned
> because I think it is the less damaging thing to do to current
> Markdown text and because it makes sense visually.

Seems like the wrong fix to me. I have a bunch of documents which
rely on the fact that I can number my lists any way I like. After
all, it has always been a deliberate feature. To break something
that you explicitly allowed previously seem, well, not like the
smartest move.

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 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 list, the marker be
required to be indented at least three spaces more than the
preceeding item.

Regards,
-- 
Aristotle Pagaltzis // 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: numbered list bug in markdown.pl?

[Michel Fortin]

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 them in plain text, and  
when there is *less* indentation, having a sublist formed is  
counter-intuitive to me.  I would prefer to have it keep them as  
part of the same list, but would possibly understand if it ended  
the current list and started a new one.  Making less-indented  
numbers into a sublist just seeems weird, especially since using  
0-3 spaces to start the first list item is allowed by spec.


I consider that as a bug too. But it seems to be due to an  
undocummented, but wildly used, feature of Markdown. This may make it  
hard to solve while still preserving backward compatibility.


Currently, something like this produce a nested list inside the first  
list item:


1. List item
 1. Sublist item
2. List item

The problem Jacob have occurs when you right-align list markers which  
are not always the same lenght. As a general case, something like  
this is expected to produce one list, but currently produce two  
nested list:


 1. List item
10. List item
20. List item
 2. List item

Any solution to this problem must absolutly preserve left-aligned  
markers too. This should be equivalent to the previous example:


1.  List item
10. List item
20. List item
2.  List item

And this too:

1. List item
10. List item
20. List item
2. List item

The problem is that in these three cases, the alignment is different;  
there is no single reference to take into account (the number, the  
dot, or the text). If we want to preserve backward compatibility, we  
would need to support sublists just as they exists currently too. For  
example would yeild two sublists:


1. List item
 10. Sublist item
20. List item
 2. Sublist item

But how is the second sublist item different from the first 1-10-20-2  
example of this post:


 1. List item
10. List item
20. List item
 2. List item

?

It is clear now that to solve that problem, we have to break  
something else. That something could be the currently undocumented  
way nested lists are created by less than four space, or it could be  
a requirement for ordered markers. Either way there is a risk of  
breaking something.


Personally, I'd go the route of requiring an increasing character  
count for numeric markers when they are right-aligned because I think  
it is the less damaging thing to do to current Markdown text and  
because it makes sense visually. The previous example would be  
equivalent to this:


1.  List item
10. List item
20. List item
2.  List item

As would this:

 1. List item
2. List item
3. List item
 4. List item

Not perfect, as it still breaks the rule saying you can use any  
number as list marker when numbers are more than one character and  
right-aligned, but it is the best compromise I can think of. What do  
you think?



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: numbered list bug in markdown.pl?

[Joseph Lorenzo Hall]

On 7/12/06, Jacob Rus <[EMAIL PROTECTED]> wrote:

Waylan Limberg wrote:
> On 7/9/06, Carl-Johan Kihlbom <[EMAIL PROTECTED]> wrote:
>> I'm guessing it's because you have different indent levels. Try
>> removing the spaces before 1-9.
>
> I'll second that. In my observation Python is very picky about the
> four spaces of indent, while Perl seems to notice any amount of indent
> (one space is often enough) even though the syntax[1] tells us we need
> four spaces. To see what I mean, try adding a couple more spaces to
> 1-9 in your 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 Student, UC Berkeley, School of Information
<http://josephhall.org/>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: numbered list bug in markdown.pl?

[Jacob Rus]

Waylan Limberg wrote:

On 7/9/06, Carl-Johan Kihlbom <[EMAIL PROTECTED]> wrote:

I'm guessing it's because you have different indent levels. Try
removing the spaces before 1-9.


I'll second that. In my observation Python is very picky about the
four spaces of indent, while Perl seems to notice any amount of indent
(one space is often enough) even though the syntax[1] tells us we need
four spaces. To see what I mean, try adding a couple more spaces to
1-9 in your 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. 
 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.  I 
would prefer to have it keep them as part of the same list, but would 
possibly understand if it ended the current list and started a new one. 
 Making less-indented numbers into a sublist just seeems weird, 
especially since using 0-3 spaces to start the first list item is 
allowed by spec.


-Jacob

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: numbered list bug in markdown.pl?

[Waylan Limberg]

On 7/9/06, Carl-Johan Kihlbom <[EMAIL PROTECTED]> wrote:

I'm guessing it's because you have different indent levels. Try
removing the spaces before 1-9.


I'll second that. In my observation Python is very picky about the
four spaces of indent, while Perl seems to notice any amount of indent
(one space is often enough) even though the syntax[1] tells us we need
four spaces. To see what I mean, try adding a couple more spaces to
1-9 in your example and run it through both to see what you get.

[1]: http://daringfireball.net/projects/markdown/syntax



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. 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 a numbered list
> Blah
> This is another list item
> 
> Ok, weird bug here
> It's really bothering me
> 
> 
>
> Interestingly, I don't get this from the [python markdown][1], instead
> getting one list, as desired.
>
> Anyone know what's up?  Or has this already been fixed?
>
> -Jacob
>
> [1]: http://www.freewisdom.org/projects/python-markdown/
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss




--

Waylan Limberg
[EMAIL PROTECTED]
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: numbered list bug in markdown.pl?

[Carl-Johan Kihlbom]

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. 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 a numbered list
Blah
This is another list item

Ok, weird bug here
It's really bothering me



Interestingly, I don't get this from the [python markdown][1], instead
getting one list, as desired.

Anyone know what's up?  Or has this already been fixed?

-Jacob

[1]: http://www.freewisdom.org/projects/python-markdown/

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

numbered list bug in markdown.pl?

[Jacob Rus]

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 a numbered list
Blah
This is another list item

Ok, weird bug here
It's really bothering me



Interestingly, I don't get this from the [python markdown][1], instead 
getting one list, as desired.


Anyone know what's up?  Or has this already been fixed?

-Jacob

[1]: http://www.freewisdom.org/projects/python-markdown/

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[John Gruber]

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
> correctly:
> 
> 1.foo*bar baz*quux
> 2.foobar  href="#">bazquux
> 
> Of course, the second option is a lot more complex to implement
> and at the same time unlikely to be what the user actually meant.

Good catch.

I think the first solution is better.

-J.G.
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

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

[Waylan Limberg]

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 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 implement
and at the same time unlikely to be what the user actually meant.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss




--

Waylan Limberg
[EMAIL PROTECTED]
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Bug: invalid nesting of inline markup across link labels

[A. Pagaltzis]

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 implement
and at the same time unlikely to be what the user actually meant.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss